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Brief Summary Text - BSTX (4): 

In one aspect of the present invention, a telecom platform forming an 
interface between application programs performing telecommunications functions 
and an operating system running on at least one node at a site supporting the 
application programs, and further forming an interface between the application 
programs and a telecommunications network. The telecom platform includes 
network management processes operable to provide inter-node configuration, 
monitoring and management functionality, node management processes operable to 
provide node initialization, configuration, monitoring, and management 
functionality, event processes operable to provide initialization, termination, 
and distribution of tasks in response to predetermined events, common processes 
operable to provide a library of a plurality of programming tools for the 
development of the application programs, communications processes operable to 
provide message handling functionality, and distributed object processes 
operable to provide a distributed database repository for object -based 
communications. 



Brief Summary Text - BSTX (5): 

In another aspect of the present invention, a method of providing a software 
interface between application programs performing telecommunications functions 
and an operating system running on at least one node at a site supporting the 
application programs, and further forming an interface between the application 
programs and a telecommunications network is provided. The method includes 
supplying network management processes operable to provide inter-node 
configuration, monitoring and management functionality, supplying node 
management processes operable to provide node initialization, configuration, 
monitoring, and management functionality, supplying event processes operable to 
provide initialization, termination, and distribution of tasks in response to 
predetermined events, supplying common processes operable to provide a library 
of a plurality of programming tools for the development of the application 
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programs, supplying communications processes operable to provide message 
handling functionality, and supplying distributed object processes operable to 
provide a distributed database repository for object- based communications. 



Drawing Description Text - DRTX (29): 

FIG. 21 is a simplified block diagram of the distributed object messaging 
environment according to an embodiment of the present invention; 



Drawing Description Text - DRTX (30): 

FIG. 22 is a simplified block diagram of the internal debugging and tracing 
object relations according to an embodiment of the present invention; 



Detailed Description Text - DETX (4): 

As shown in FIG. 1 , telecom platform 10 is comprised of three distinct 
software layers 14-16. Layer #1 is a telecom platform application programming 
interface (API) layer 14; layer #2 is a telecom platform services layer 15; and 
layer #3 is a systems interface layer 16. Telecom platform API layer 14 
provides the communication methods for accessing telecom platform services 
layer 15, which is comprised of telecommunications middleware services. 
Telecom platform services layer 15 is the software layer that provides the most 
commonly needed middleware services for a UNIX-based telecommunications system, 
for example. System interface layer 16 is comprised of operating system (OS) 
API and the network links. System interface layer 16 defines the functions of 
process and thread management, memory management, timers, file system, 
communication, interface to hardware devices, and other system components. 
Telecom platform 10 allows higher level client applications 12 to be decoupled 
from the operating system and network. By using telecom platform 10, 
developers may write applications without having to master the intricacies of 
the underlying services, such as the operating system and the network, that 
perform the work on behalf of the application. 



Detailed Description Text - DETX (16): 

The telecom platform internal architecture is described from both the 
logical and physical partitioning perspectives. The logical partitioning 
decomposes the telecom platform into distinct functional areas as shown in FIG. 
4. Each functional area contains a cohesive group of classes, which together 
provide one particular system function. The physical partitioning describes 
the concrete software and hardware decomposition of the system's context. The 
services provided by telecom platform 10 may be partitioned into two groups: 
application services 60 and core services 62. Application services may include 
services that perform information and problem report (IPR)/alarm 64, statistics 
65, dictionary 66, graphical user interface (GUI) 67, and host maintenance 
simulator (HMS). IPR/alarm services 64 provide a standard mechanism to inform 
the system user of error conditions and other pertinent system information. 
Statistics services 65 provides the methods to access system-wide measurement 
data and to generate reports based on the collected data. Dictionary services 

66 provide classes that are designed to support data storage (persistent, 
shared or private) and access to the data. Graphical user interface services 

67 provide primitive abstractions for building GUI applications, and access to 
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system utilities and to the system itself, e.g., xterm window and operating 
system utility programs. Host maintenance simulator services 75 provide a 
method of interfacing with the telecom platform when there is only one node 
within the system or when there is not a host to which to connect. It is 
through the host that control and operation of the platform is made possible. 



Detailed Description Text - DETX (17): 

Core services 62 may include services that perform network management 68, 
node management 69, distributed object 70, communications 72, common functions 
73, and event handling 74. Network management services 68 directs network 
activities, e.g., configuration of nodes and network-level fault processing. 
Node management services 69 directs node-level processes, e.g., node status 
reporting and link management. Distributed object services 70 provide a 
distributed database repository for object-based communication in a 
multi-processing environment. Communications services 72 provide the mechanism 
for handling messages across interprocessing links external to the platform. 
Common services 73 provide a library of programming tools to aid in the rapid 
development of processes designed to run on or within the telecom platform. 
Event services 74 provide the capability to initiate, terminate, and/or 
distribute specific actions significant to a task. 



Detailed Description Text - DETX (19): 

FIG. 5 further shows the telecom platform services and their dependencies. 
The developer accesses all of the core and application services through telecom 
platform application program interfaces 14. The developer may also access the 
operation system, network, and third party software/hardware if the need 
arises. Interprocess object- based communication is handled by communication 
services 72. Most of the core and application services dependent on 
communication services 72 and common services 73 to perform their respective 
functions. Graphical user interface services 67 may only be dependent on 
communication services 72. The arrows in FIG. 5 indicate the dependency 
relationships between the services. 



Detailed Description Text - DETX (25): 

The class name for the network platform manager is NetPM. NetPM is 
responsible for providing management functionality of the platform resources. 
The platform is a distributed system consisting of multiple nodes or servers 
which provide processing power for specific services, such as calling card or 
credit card validation. The service provided by a server is determined by the 
configurable elements residing on the node. NetPM manages all the 
configuration data associated with the platform. Configuration data includes 
information about the hardware, such as the TCP/IP address of a server, status 
information, such as server and query status, software configuration 
information, such as application type, node name, and information relating to 
the individual configurable elements. 



Detailed Description Text - DETX (32): 

NetPM uses a NetMAP object to manage all the configuration data. NetPM also 
uses a persistent dictionary to retain server status, query status, and 
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scheduled actions information across platform manager resets. A Disk File 
Dictionary object is used to manager this dictionary. NetPM is responsible for 
maintaining the integrity of the configuration data between the two platform 
manager servers. NetPM uses a persistent dictionary, database equalization, 
and auditing to maintain the integrity of the data. 



Detailed Description Text - DETX (46): 

NetPM provides, partially through the use of two alias objects, two sets of 
routing options to other processes wishing to communicate with NetPM. NetPM 
provides a local, and a global active-standby option. In the local option, all 
NetPM client requests are sent to the NetPM server object in the same node as 
the client object . In the global active-standby option, all NetPM client 
requests are sent to the globally (i.e. possibly inter-nodal) available active 
NetPM server object . 



Detailed Description Text - DETX (48): 

NetPM also provides a function to initialize the majority of the Server 
configuration data. This function expects a ServerlnfoMsg object as input. 



Detailed Description Text - DETX (53): 

NetPM is also responsible for time synchronization within the server 
network. Time synchronization consists of three major parts, as shown in FIG. 
7B. The first part is for active platform manager 100 to equalize its local 
time with the time of the host. This includes converting the host's (110) time 
into a usable form and informing the NodePMs 112 on platform manager nodes 100 
and 102 to perform an adjtime( ) function to adjust their clocks in line with 
host 1 1 0. NetPM 1 04 also informs the host ticker class of the new host time 
when it receives the time message. An xntp process 120 then synchronizes the 
application nodes' (121) time with the time of the platform manager nodes 100 
and 102. Each of the platform manager nodes 100 and 102 are configured as xntp 
master sources of time. The xntp daemon slaves 122 on application nodes 121 
choose one of the master xntp daemons 120 on platform manager nodes 100 and 102 
to keep in synch with. Finally, whenever an unsolicited Set Time message is 
received from host 110, the network's time is the same as the received time. 



Detailed Description Text - DETX (55): 

NetPM 104 is an object with its own thread of control. After building up 
its NetMAP lists, NetPM 104 goes into an infinite loop waiting for requests. 
NetPM 104 notifies ConfigMgr 108 whenever there is a change in the service or 
query status of a server. NetPM 104 also sends these status changes to all the 
NodePMs 112 in the platform. NetPM 104 notifies the specific NodePM 112 to 
enable, or disable, query processing. NetPM 104 provides service status 
synchronization functionality. NetPM 104 builds up the IPU information for the 
servers in the platform and passes this information to the specific NodePM 112 
in the BootNotify member function. NetPM, in all the configuration requests 
for degradation of service (i.e. GraceDown, ImmedDown, GraceHalt, and 
ImmedHalt), notifies the specific NodePM 112 of the desired state of the 
server. NetPM 104 does several things when a server restore is requested. 
First, NetPM 104 obtains the current status of the server from the specific 
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NodePM 112. Second, if the returned status is out-of-service/minimum-software, 
NetPM 104 sends the specific NodePM 112 the relevant NodeSpeclnfo. Third, 
NetPM 104 sends the relevant configurable element descriptor information to the 
specific NodePM 112. Lastly, NetPM tells the specific NodePM to restore to 
service. 



Detailed Description Text - DETX (61): 

The class name of Network System Integrity is NetSI. NetS1 106 manages 
network system integrity for the platform manager. NetS1 106 receives 
notifications of server downgrades and communication faults from the NodeSI on 
the faulted node. NetS1 106 determines what action should be taken based on 
the data given by NodeSI. If the node indicates a downgrade, NetSI will take 
the appropriate action to downgrade the node from the network level to the 
desired downgraded state. If the node indicates a communication fault, NetSI 
106 will determine what node (if any) is at fault from data received previously 
and will take action to downgrade the faulted node if necessary. When NetSI 
determines that a downgrade is required for a node, NetSI calls the appropriate 
NetPM operation to perform the downgrade. If a change in active status is 
required, NetSI calls the appropriate NetPM operation to set the active status. 
After NetPM is called to perform the downgrade, NetSI notifies ConfigMgr that 
the status is changing for a particular node. This allows the host to be 
informed immediately that a node is being downgraded. NetSI then writes an 
entry to the network configuration report indicating the status change and 
reason for it. NetSI downgrades nodes to the legal service state based on the 
current state of the node. 



Detailed Description Text - DETX (68): 

Referring to FIGS. 7C and 7D, process interaction between node management 
and network management is shown. Constant monitor (ConMon) 132 is an instance 
of an object running on an application node 136. ConMon 132 detects a faulted 
process or a failed configurable element, it notifies a service management 
process program 134. Service management process 134 determines if the 
configurable element failure causes the process to fall below its threshold 
level. If it does not, the service management process 134 restarts the 
configurable element. However, if the configurable element does fall below its 
threshold level then service management process 134 generates a configurable 
element status change message and forwards the notification to NodeS1 130. 
NodeSI forwards the configurable element status change to NodePM 112. NodePM 
112 determines whether the configurable status change affects the run level of 
the node, which could cause a downgrade of the node. If the node is to be 
removed, NodePM 112 provides instructions to service management process 134 to 
remove all of the configurable elements necessary to achieve the downgraded 
state. NodePM 134 notified the NetPM 104 of the node status change. NetPM 104 
performs a calculation to determine if the node status change affects the 
processor service group and application status. NetPM's calculation also 
determines if an auto-action, such as removing a node from in-service to 
min-set and restoring it again, should be performed on the node. If the node 
is to be removed, then the node status change is forwarded from NetPM to 
ConfigMgr 108. ConfigMgr notifies host 140 of the state change for the node, 
processor service group, and application. These state changes can be displayed 
or printed in a report. 
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Detailed Description Text - DETX (72): 

The Configuration management subsystem (class name: ConfigMgr) provides the 
control interface between the SCP Host and Server components. All operations 
that can be performed on the server network are defined in this interface. The 
Configuration Management subsystem implements the following features: 



Detailed Description Text - DETX (137): 

Instantiates the NodeMAP object, and after getting the configuration 
information on the minimum Configurable elements that need to be configured on 
each servers, it brings up the server node to a minimal operational state 
(OS-MIN). From this state the server node is allowed only a minimum set of 
functionality such as bringing the rest of the processes up. The configuration 
data provided in each node's NodeMAP determines the capabilities of each server 
node (server nodes withplatform managercapabilities versus server nodes with 
query processing capabilities). 



Detailed Description Text - DETX (138): 

Creates the NodePM server object to handle the NetPM requests to perform 
operations within the same server node. 



Detailed Description Text - DETX (139): 

Per NetPM request, NodePM (through operations provided by its server object) 
can perform the following operations: 



Detailed Description Text - DETX (147): 

The Node System Integrity subsystem (class name NodeSI) provides fault 
isolation and monitoring services within a single server node. All process 
failures are logged by this subsystem and forwarded to node Management for 
recovery action. Node System Integrity implements the following features: 

Detailed Description Text - DETX (152): 
Faults detected by Constant Monitor object on each process. 



Detailed Description Text - DETX (157): 

NodeSI monitors the disk utilization on each server node, the issues 
appropriate IPR when the total capacity used on a particular file system 
exceeds a certain threshold. NodeSI communication with other objects is 
handled via the DOME interface. NodeSI gets the list of all IPUs in the 
configuration from NodePM. An array is set up containing the following 
information from each IPU: 



Detailed Description Text - DETX (192): 

Each Configurable element process is required to instantiate the Constant 
Monitor object, in order to detect and report abnormal conditions/events 
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generating different signals on the process. Constant Monitor reports these 
conditions via NotifyFault( ) operation of NodeSI. In case of failure to 
communicate the fault to NodeSI, the Constant Monitor may HALT the node, 
depending on the options set at the time of its instantiation. 



Detailed Description Text - DETX (208): 

FIG. 10 outlines the messages protocol that is used between SM and a 
Configurable element. If a configurable element cannot for link a service 
management interface (SMI) object into it, service management can still start 
that configurable element, but many of the features that service management 
provides will not be available. 



Detailed Description Text - DETX (210): 

The event manager subsystem provides the ability for a users to genetically 
issue event notification to one or more registered parties. Multiple 
Event::Manager object instances may exist in the system. A node level 
Event::Manager exists on all nodes. Other Event: :Manager instances may also 
exist to provide the ability for interested parties to register for events that 
are special to a process. The eventmanagerimpl program provides an 
Event::Manager object instance for the mode that it is running on. Events that 
are relevant to a node get issued through that Event::Manager instance. Users 
interested in events on a particular node can bind to that nodes Event: :Manager 
instance by using that nodes name as the Event::Manager name. Programs can 
also embed an Event::Manager object within their program. The IprMgrlmpI 
program is an example of a program that does this. The IprMgrlmpI has an 
Event::Manager named IprEventMgr. Users that wish to receive IPR events. 
Users that are interested in a particular event may register with a particular 
Event::Manager instance to receive that event through that Event::Manager 
instance. The Event: :Manager does not persistently store the list of 
registered parties. If the Event::Manager tries to forward an event to a 
Event:: Receiver that has gone away, that Event::Receiver is removed form the 
list. 



Detailed Description Text - DETX (21 1): 

FIG. 11 shows two examples of uses for Event::Manager 250 in the telecom 
platform system. The eventmanagerimpl 252 contains the node Event::Manager 
object instance 250. The NodePMMain telecom platform program 254 uses this 
Event::Manager 250 to issue an event when the node changes state. The 
application program 256 then creates an Event-Receiver object 268 and passed a 
CORBA object reference to the register call on the "Node123 H Event: :Manager 
250, When NodePMMain 254 generates an event by calling notify on the "Node123" 
Event-Manager 250, that Event:Manager250 will find all of the Event:: Receiver 
objects 258 that have registered to receive this event. Seeing that the 
application program has registered for this event, the Event::Manager 250 will 
call the notify( ) method on that Event::Receiver object 258 which will cause 
the notify ( ) method to be invoked in the Application program 256. In the 
example above, the Application program 256 has also registered with the 
"IprEventMgr" Event: Manager 260 in the IprMgrlmpI program 262. When 
NodePMMMain 254 uses the IprMgrlmpI interface to issue an IPR, the IprMgrlmpI 
program 262 does the lookup on that IPR and performs verification, and calls 



11/17/2003, EAST Version: 1.4.1 



notify ( ) on the "IprEventMgr" Event::Manager 260. This cause that 
Event::Manager 250 to forward the generated event to the Event: :Receiver 264 in 
the application program 256 that was passed in the register call. 



Detailed Description Text - DETX (216): 

Referring to FIG. 12, the IprMgrlmpI program is the collection point for all 
IPRs in a telecom platform site. This program contains the IprMgrlmpI CORBA 
server object . The IprMgrlmpI object runs on each of the active/standby 
platform manager nodes. The active/standby state that the IprMgrlmpI reacts to 
is the node level active/standby state of the telecom platform manager nodes. 
The standby IprMgrlmpI object will unpublish its interface, and the active 
IprMgrlmpI object will publish its CORBA interface when the platform manager 
nodes change active/standby state. By doing this, client users of both the 
IprMgr and IPRCIient interfaces will have their IPRs forwarded to the active 
IprMgrlmpI object . 



Detailed Description Text - DETX (219): 

The IPR subsystem has a two external interfaces: the IPRCIient interface 274 
and the CORBA IPR interface 276. The IPRCIient interface 276 exists for 
backward compatibility with previous PAConfigurable element releases. Once the 
issued IPR from the IPRCIient interface 274 has been converted by the IPRCIient 
code, an IPR is issued using the IprMgrlmpI CORBA interface to route the IPR to 
the active IprMgrlmpI object . This interface still uses the LOCIPRDB.DSK IPR 
dictionary as input for converting the old PAConfigurable element IPRs to the 
current IPR subsystem format. This requires that a LOCIPRDB.DSK reside on each 
node that has programs that issue IPRs. The LOCIPRDB.DSK dictionary was used 
in the previous releases to do IPR verification before IPRs were forwarded to 
the host. The RegisterlPR utility is used to enter IPRs into the LOCIPRDB.DSK 
dictionary. The fields in the database entries include: ASCII key (IPR text), 
host IPR number, IPR priority, number of data words used, and data word format. 
In order to test the IPRMgr, IPRs must be defined in ipr.in which will be 
converted to a keyed dictionary (via the RegisterlPR utility). 



Detailed Description Text - DETX (220): 

The IprMgrlmpI interface is a CORBA IDL interface. If an IPR is issued 
using this interface, it is not required to be entered in the LOCIPRDB.DSK 
dictionary. When the IprMgrlmpI object receives an issued IPR, it looks it up 
in its IPR dictionary and constructs an IPR event to be issued. The IPR event 
contains information that was passed from the client that issued the IPR, and 
information from the IPR dictionary. IPRs must be added to the IPR dictionary 
and the MegaHub host IPR dictionaries prior to issuance of an IPRs. The 
IprDriver tool is used to add IPRs to the IprMgrlmpI IPR dictionary. The 
reformat and reformat2 scripts exists to assist in converting a VAX IPR file to 
a format that can be used with the IprDriver to populate the IprMgrlmpI IPR 
dictionary. 



Detailed Description Text - DETX (229): 

Referring to FIG. 15, the data collection subsystem (DC) 298 provides the 
traffic measuring functionality for the application programs within a node. 
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These measurements are counts recorded by the PegCounter class and elapsed time 
recorded by the TimeMeter class , PegCounter 299 testing will indirectly test 
shared memory 300 and semaphores. Client processes 301 peg to shared memory 
300, and data collection 298 collects from shared memory 300 and sends to 
DCMaster 302. Every 30 minutes, data collection 298 sends the DCMaster 302 (in 
the active platform manager node) the 30 minutes worth of peg counter slots 299 
and then data collection zeros out those slots. The active platform manager 
node 304 updates the standby platform manager node 306. 



Detailed Description Text - DETX (236): 

The threshold counter subsystem may be implemented as an object request 
broker (ORB) distributed object, using the orbeline ORB implementation. 
Applications are connected via Orbeline to a server object resident in the 
platform manager nodes. The server reports counter threshold crossings to 
applications via distributed object messaging environment (DOME). The server 
object are created by the thresholds counter server process, TCServer. Each 
TCServer process also communicates via Orbeline with the TCServers on remote 
nodes so that counters can be synchronized across sites. The TCServer keeps 
all counters in persistent storage using the persistent dictionary supplied in 
the common services library as template class RepShmDict. 



Detailed Description Text - DETX (238): 

Referring to FIG. 18, the threshold counter subsystem 360 API hides the 
orbeiine-specific portions of the implementation from the application 
programmer. Instead, the client side of the subsystem will consist of two 
layers: an ORB-independent layer 362, and an orbeline-dependent layer 364. 
Although the orbeiine-specific implementation of the subsystem is hidden from 
the application programmer, the distributed nature of the subsystem is not. To 
minimize the time required for counter increments, counter increments are 
buffered in the API, and sent to the server in batches. This means that the 
application is unable to receive immediate notification of the success or 
failure of some operations on the API objects . 



Detailed Description Text - DETX (241): 

As shown in FIGS. 19 and 20, the Message Handling subsystem 370 provides 
message based interprocessor communications services. Generally all 
interprocess communication between processes on the server nodes is carried out 
via the Distributed Object Messaging Environment (DOME) 372 shown in FIG. 21 . 
DOME 372 uses the Message Handling subsystem 370 when information must be 
communicated across node boundaries. The Message Handling subsystem 370 is 
also used for communication to non-server external systems such as the SCP 
Host. The Message Handling subsystem 370 implements the following features. 



Detailed Description Text - DETX (250): 
Distributed Object Services 



Detailed Description Text - DETX (251): 
Referring to FIG. 21 , DOME 372 is a client/server interface used for 
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interprocess client/server communication. It contains server interfaces 382 
which allow server processes 382 to register objects and member functions for 
use by client processes 384. DOME 372 contains a shared memory database 380 to 
store the server descriptions and a stand-alone DOMEServices process (domeSrv) 
which maintains the server object descriptions from other nodes. It also 
contains client interfaces 384 which provide access to any registered server 
object in the node's DOME database. 



Detailed Description Text - DETX (252): 

The Interprocess Communications subsystem consists mainly of DOME. DOME 
provides the ability for a process to register a server object and it's methods 
in a way that allows other processes in the system to invoke those methods. 
DOME supports various modes of registration and access including many special 
routing options that aid in the development of fault resilient software. 
Features implemented by the Interprocess Communications subsystem include: 



Detailed Description Text - DETX (253): 
Registered Object Name Management across nodes and sites 



Detailed Description Text - DETX (255): 
Active/Standby Object request routing 



Detailed Description Text - DETX (256): 
Load Shared Object request routing 



Detailed Description Text - DETX (257): 
Broadcast Object request routing 



Detailed Description Text - DETX (258): 
Blocking/Non-Blocking Object requests 



Detailed Description Text - DETX (261): 
Command Line Object 



Detailed Description Text - DETX (262): 
Trace Object 



Detailed Description Text - DETX (263): 
Shared Memory Object 



Detailed Description Text - DETX (264): 
Semaphore Object 
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Detailed Description Text - DETX (265): 
Keyed Dictionary Object 



Detailed Description Text - DETX (266): 
List Object 



Detailed Description Text - DETX (267): 
Replicated Keyed Dictionary Object 



Detailed Description Text - DETX (268): 
Shared Memory Dictionary Object 



Detailed Description Text - DETX (270): 
DbgTrace Object 



Detailed Description Text - DETX (272): 

The DbgCntl interface 404 is the control interface for DbgTrace objects 400. 
It allows users to specify many different aspects of the DbgTrace facility 400. 
This interface allows users to do the following things on DbgTrace objects 400: 



Detailed Description Text - DETX (280): 

The DbgTrace facility 400 allows the users to create different DbgTrace 
objects 400 that can each belong to one of multiple groups. This allows users 
to have a unique mask value for each group. All traces issued through the 
DbgTrace interface 400 get stored in an internal message buffer. Users can 
also specify whether to issue traces to standard error in addition to the 
internal buffer. 



Detailed Description Text - DETX (281): 
Trace Object 



Detailed Description Text - DETX (282): 

The Trace object provides the user the ability to optionally issue trace 
messages to standard error. When the user issues a trace, a mask is specified 
which represents the trace level that this trace will be output for. The Trace 
interface allows the user to specify a mask which all instances of trace in 
that UNIX process will use to determine whether or not to issue the trace 
message. The trace mask may supports eight unique mask values. 



Detailed Description Text - DETX (284): 

Referring to FIG. 23, Dictionary Management provides classes which are 
designed to support data storage and access. Dictionaries can be stored on 
disk (persistent) or stored in memory. Dictionaries can also be private (used 
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by local process only) or shared (accessible by multiple processes). The 
purposes of these dictionaries are defined by the application program. The 
primary interaction between DmsMaster 430 and DmsServer 432 is that DmsMaster 
430 updates DmsServer 432 when it receives an update message from the 
application. DmsMaster 430 runs as active/standby in the platform manager 
nodes, and DmsServer 432 runs in all (or a subset) of the IPUs. 



Detailed Description Text - DETX (286): 

Event services provide the capability to generate and distribute specific 
occurrences significant to a task among loosely coupled processes. An example 
of an event is the completion of an input/output transfer. The event services 
may be a CORBA-based interprocess communication facility. It uses standard 
CORBA requests that result in the execution of an operation by an object . This 
is accomplished through the event manager implemementation program. 



Detailed Description Text - DETX (287): 

By defining two distinct roles for objects, communication is decoupled 
between objects : creating asynchronous communication. One object receives and 
accumulates new events, while the other object registers an interest to be 
forwarded these new events. This is accomplished by two CORBA classes. 
EventManager and EventReceiver. EventManager provides an interface definition 
language (IDL) interface for receiving new events. EventReceiver provides an 
interface definition language interface for clients interested in receiving 
events. 



Claims Text - CLTX (7): 

supplying distributed object processes operable to provide a distributed 
database repository for object- based communications. 



Claims Text - CLTX (63): 

distributed object processes operable to provide a distributed database 
repository for object -based communications. 
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Brief Summary Text - BSTX (7): 

Simple Network Management Protocol (SNMP) is a standard for network 
management that can be employed by the network manager to manage the devices on 
the network. Each SNMP-manageable device has a Management Information Base 
(MIB) that stores objects or variables representing different characteristics 
of a device including its IP and MAC addresses. The network manager discovers 
the identity of a device by sending a GetNext request to a SNMP-manageable 
device. The response returns the IP and/or MAC addresses. 



Drawing Description Text - DRTX (2): 

For a better understanding of the nature and objects of the invention, 
reference should be made to the following detailed description taken in 
conjunction with the accompanying drawings, in which: 



Detailed Description Text - DETX (8): 

The ARP layer is used by the IP layer to translate an IP address into its 
respective MAC address. The MAC address is then used in the delivery of the 
data packet to the intended device. The ARP layer performs the address 
resolution through dynamic binding. When a device A want to resolve the IP 
address of device B, IP.sub.B, a broadcast message is sent on the network with 
IP address IP.sub.B. Device B recognizes its IP address and responds with the 
physical address. An ARP cache is used to store those recently translated IP 
and MAC addresses in order to minimize the number of address translations that 
are performed at the ARP layer. However, the MAC addresses stored in the ARP 
cache cannot be accessed by an application program at the process layer . 



Detailed Description Text - DETX (1 1): 

The local discovery node 132, 136 uses SNMP to discover the devices on the 
network. SMNP is an application program that provides multi-vendor, 
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interoperable network management. Each SNMP device is associated with a M1B 
that stores objects and/or variables representing different characteristics of 
a resource. The MIB is composed of a number of tables that are scattered 
through out the various network protocol layers. The MIB includes an "atTable" 
which is in essence, the ARP cache. An exemplary atTable is shown below as 
Table 1 . 



Detailed Description Text - DETX (18): 

The local IP and MAC discovery procedure 174 needs to determine which IP 
addresses are active. In the case of a class C network, such as an ethernet 
LAN, the network can support up to 255 IP addresses, but not all of the 255 IP 
addresses may be active. A class A network can support up to 2.sup.24 or 
16,777,216 IP addresses. Furthermore, the atTable 180 has room for a limited 
number of entries and as such, is refreshed on a periodic basis in order to 
store the most recently used entries. Due to the large number of IP addresses 
available and the space limitation of the atTable 180, the procedure 174 
executes bursts of IP addresses at a time. A burst is a subset or a predefined 
number of the IP addresses supported on a network. By operating on a select 
number of IP addresses at one time, the procedure 174 can obtain the 
corresponding MAC addresses before they are deleted from the atTable 180. 
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Brief Summary Text - BSTX (8): 

A variety of different types of software may be used to program application 
server 103 and/or client 105. One programming language is the Java.TM. 
programming language. Java.TM. application object code is loaded into a 
JavaTM. virtual machine ("JVM"). A JVM is a program loaded onto a processing 
device which emulates a particular machine or processing device. More 
information on the Java.TM. programming language may be obtained at 
http://www.javasoft.com, which is incorporated by reference herein. 



Brief Summary Text - BSTX (10): 

RMI 100a is a distributed programming model often used in peer-to-peer 
architecture described below. In particular, a set of classes and interfaces 
enables one Java.TM. object to call the public method of another Java.TM 
object running on a different JVM. 



Brief Summary Text - BSTX (16): 

FIG. 2 illustrates peer-to-peer architecture 214. Processing devices 216, 
217 and 218 are coupled to communication medium 213. Processing devices 216, 
217, and 218 include network software 210a, 210b, and 210c for communicating 
over medium 213. Typically, each processing device in a peer-to-peer 
architecture has similar processing capabilities and applications. Examples of 
peer-to-peer program models include Common Object Request Broker Architecture 
("CORBA") and Distributed Object Component Model ("DCOM") architecture. 



Brief Summary Text - BSTX (31): 

According to another aspect of the present invention, the first processing 
device includes an Enterprise Java.TM. Bean object . 
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Brief Summary Text - BSTX (46): 

According to another aspect of the present invention, the article of 
manufacture comprises a first set of digital information, including an 
Enterprise Java.TM. Bean object for selecting a service provider from a 
plurality of service providers. 



Drawing Description Text - DRTX (12): 
FIG. 5b illustrates an EJB object architecture; 



Detailed Description Text - DETX (4): 

FIG. 3a illustrates a simplified block diagram 380 of the software layers in 
a processing device of a clustered enterprise Java.TM. system, according to an 
embodiment of the present invention. A detailed description of a clustered 
enterprise Java.TM. distributed processing system is described below. The 
first layer of software includes a communication medium software driver 351 for 
transferring and receiving information on a communication medium, such as an 
ethernet local area network. An operating system 310 including a transmission 
control protocol ('TCP") software component 353 and internet protocol ("IP") 
software component 352 are upper software layers for retrieving and sending 
packages or blocks of information in a particular format. An "upper" software 
layer is generally defined as a software component which utilizes or accesses 
one or more "lower" software layers or software components. A JVM 354 is then 
implemented. A kernel 355 having a remote Java.TM. virtual machine 356 is 
then layered on JVM 354. Kernel 355. described in detail below, is used to 
transfer messages between processing devices in a clustered enterprise Java.TM. 
distributed processing system. Remote method invocation 357 and enterprise 
Java.TM. bean 358 are upper software layers of kernel 355. EJB 358 is a 
container for a variety of Java.TM. applications. 



Detailed Description Text - DETX (12): 

In particular, server 302, server 303, and client 304 have kernels 302b, 
303b, and 304b, respectively. In particular, in order for two JVMs to 
interact, whether they are clients or servers, each JVM constructs an RJVM 
representing the other. Messages are sent from the upper layer on one side, 
through a corresponding RJVM, across the communication medium, through the peer 
RJVM, and delivered to the upper layer on the other side. In various 
embodiments, messages can be transferred using a variety of different 
protocols, including, but not limited to, Transmission Control 
Protocol/Internet Protocol ("TCP/IP"), Secure Sockets Layer ("SSL"), Hypertext 
Transport Protocol ("HTTP") tunneling, and Internet InterORB Protocol ("MOP") 
tunneling, and combinations thereof. The RJVMs and socket managers create and 
maintain the sockets underlying these protocols and share them between all 
objects in the upper layers. A socket is a logical location representing a 
terminal between processing devices in a distributed processing system. The 
kernel maintains a pool of execute threads and thread manager software 
component 364 multiplexes the threads between socket reading and request 
execution. A thread is a sequence of executing program code segments or 
functions. 
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Detailed Description Text - DETX (25): 

The first line establishes a session with the acme server using the t3 
protocol. If RJVMs do not already exist, each JVM constructs an RJVM for the 
other and an underlying TCP socket is established. The client-side 
representation of this session-the T3Client obiect -and the server-side 
representation communicate through these RJVMs. The server-side supports a 
variety of services, including database access, remote file access, workspaces, 
events, and logging. The second line obtains a LogServices object and the 
third line writes the message. 



Detailed Description Text - DETX (26): 

Clustered enterprise JavaTM. computer architecture 300 also supports a 
server-neutral syntax consistent with a peer-to-peer distributed processing 
architecture. As an example, the following code fragment obtains a stub for an 
RMI object from the JNDI-compliant naming service on a server and invokes one 
of its methods. Hashtable env=new Hashtable( ); env.put(ContexLPROVIDERJJRL, 
M t3://acme:7001");env.put(ContextJNITIAL_CONTEXT_FACTORY, 
"weblogicjndi.WebLogicinrtialContextFactory"); Context ctx=new 
InrtialContext(env); Example e=(Example) ctx.lookup( M acme.eng.example"); 
res u lt=e . exam pie (37) ; 



Detailed Description Text - DETX (27): 

In an embodiment, JNDI naming contexts are packaged as RMI objects to 
implement remote access. Thus, the above code illustrates a kind of RMI 
bootstrapping. The first four lines obtain an RMI stub for the initial context 
on the acme server. If RJVMs do not already exist, each side constructs an 
RJVM for the other and an underlying TCP socket for the t3 protocol is 
established. The caller-side object-the RMI stub~and the callee-side 
obiect- -an RMI impl-communicate through the RJVMs. The fifth line looks up 
another RMI object an Example, at the name acme.eng.example and the sixth line 
invokes one of the Example methods. In an embodiment, the Example impl is not 
on the same processing device as the naming service. In another embodiment, 
the Example impl is on a client. Invocation of the Example object leads to the 
creation of the appropriate RJVMs if they do not already exist. II. 
Replica-Aware or Smart Stubs/EJB Objects 



Detailed Description Text - DETX (28): 

In FIG. 3c, a processing device is able to provide a service to other 
processing devices in architecture 300 by replicating RMI and/or EJB objects . 
Thus, architecture 300 is easily scalable and fault tolerant. An additional 
service may easily be added to architecture 300 by adding replicated RMI and/or 
EJB objects to an existing processing device or newly added processing device. 
Moreover, because the RMI and/or EJB objects can be replicated throughout 
architecture 300, a single processing device, multiple processing devices, 
and/or a communication medium may fail and still not render architecture 300 
inoperable or significantly degraded. 



Detailed Description Text - DETX (30): 
RA RMI stub 580 is a Smart stub which is able to find out about all of the 
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service providers and switch between them based on a load balancing method 507 
and/or failover method 508. In an embodiment, an RA stub 580 includes a 
replica handler 506 that selects an appropriate load balancing method 507 
and/or failover method 507. In an alternate embodiment, a single load 
balancing method and/or single failover method is implemented. In alternate 
embodiments, replica handler 506 may include multiple load balancing methods 
and/or multiple failover methods and combinations thereof. In an embodiment, a 
replica handler 506 implements the following interface: public interface 
ReplicaHandler [ Object loadBalance fObiect currentProvider) throws 
Ref resh Abort edException; Object failOver (Obiect failedProvider, RemoteException 
e) throws RemoteException; ] 



Detailed Description Text - DETX (49): 

A RMI compiler recognizes a special flag that instructs the compiler to 
generate an RA stub for an object . An additional flag can be used to specify 
that the service methods are idempotent. In an embodiment, RA stub 580 will 
use the replica handler described above and illustrated in FIG. 5a. An 
additional flag may be used to specify a different handler. In addition, at 
the point a service is deployed, i.e., bound into a clustered naming service as 
described below, the handler may be overridden. 



Detailed Description Text - DETX (50): 

FIG. 5b illustrates another embodiment of the present invention in which an 
EJB object 551 is used instead of a stub, as shown in FIG. 5a. III. 
Replicated JNDI-compliant Naming Service 



Detailed Description Text - DETX (58): 

In this example, the two calls to example may be handled by different 
service providers since the Smart stub is able to switch between them in the 
interests of load balancing. Thus, the Example service object cannot 
internally store information on behalf of the application. Typically the 
stateless model is used only if the provider is stateless. As an example, a 
pure stateless provider might compute some mathematical function of its 
arguments and return the result. Stateless providers may store information on 
their own behalf, such as for accounting purposes. More importantly, stateless 
providers may access an underlying persistent storage device and load 
application state into memory on an as-needed basis. For example, in order for 
example to return the running sum of all values passed to it as arguments, 
example might read the previous sum from a database, add in its current 
argument, write the new value out, and then return it. This stateless service 
model promotes scalability. 



Detailed Description Text - DETX (63): 

In the stateful programming model, a service provider is a long-lived, 
stateful object identified by some unique system-wide key. Examples of 
"entities" that might be accessed using this model include remote file systems 
and rows in a database table. A targeted provider may be accessed many times 
by many clients, unlike the other two models where each provider is used once 
by one client. Stubs for targeted providers can be obtained either by direct 
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lookup, where the key is simply the naming-service name, or through a factory, 
where the key includes arguments to the create operation. In either case, the 
stub will not do load balancing or failover. Retries, if any, must explicitly 
obtain the stub again. 



Detailed Description Text - DETX (64): 

There are three kinds of beans in EJB, each of which maps to one of the 
three programming models. Stateless session beans are created on behalf of a 
particular caller, but maintain no internal state between calls. Stateless 
session beans map to the stateless model. Stateful session beans are created 
on behalf of a particular caller and maintain internal state between calls. 
Stateful session beans map to the stateless factory model. Entity beans are 
singular, stateful objects identified by a system-wide key. Entity beans map 
to the stateful model. All three types of beans are created by a factory 
called an EJB home. In an embodiment, both EJB homes and the beans they create 
are referenced using RMI. In an architecture as illustrated in FIGS. 3-5, 
stubs for an EJB home are Smart stubs. Stubs for stateless session beans are 
Smart stubs, while stubs for stateful session beans and entity beans are not. 
The replica handler to use for an EJB-based service can be specified in its 
deployment descriptor. 



Detailed Description Text - DETX (65): 

To create an indirect RMI-based service, which is required if the object is 
to maintain state on behalf of the caller, the application code must explicitly 
construct the factory. A targeted RMI-based service can be created by running 
the RMI compiler without any special flags and then binding the resulting 
service into the replicated naming tree. A stub for the object will be bound 
directly into each instance of the naming tree and no service pool will be 
created. This provides a targeted service where the key is the naming-service 
name. In an embodiment, this is used to create remote file systems. V. 
Hardware and Software Components 



Claims Text - CLTX (8): 

8. An article of manufacture including an information storage medium 
wherein is stored information, comprising: a first set of digital information, 
including a Java.TM. virtual machine with a Java.TWL bean object for 
selecting a service provider from a plurality of service providers; wherein 
the Java.TM. bean object has a load balancing software component that selects 
a particular service provider, from the plurality of service providers, if both 
an affinity exists for the particular service provider and the particular 
service provider provides a service requested, and, wherein an affinity exists 
for a particular service provider when that particular service provider, or the 
server associated with the service provider, is currently participating in a 
transaction between either of the service provider or server and the client 
processing device. 



Claims Text -CLTX (9): 

9. The article of manufacture of claim 8, wherein the Java.TM. bean object 
has a failover software component for removing a failed service provider from a 
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list of service providers. 
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Brief Summary Text - BSTX (44): 

The present invention is also based, in part, on my discovery that the 
object manager and engine object component layers may be advantageously be 
designed to operate independently, thereby making possible a distributed 
computing environment, as described below in detail. I have further discovered 
that an efficient method of implementing the engine object component layer is 
by using pre-populated tables/files. I have further discovered that the engine 
management layer may be advantageously divided into a three layer structure of 
load/unload engine, dynamic linking engine function calls, and initialize 
engine setting. 



Brief Summary Text - BSTX (45): 

In accordance with one embodiment of the invention, a computer implemented 
process migrates a program specific Application Programmer Interface (API) from 
an original state into a generic interface by building an object for each 
engine. The object provides substantially uniform access to the engine and 
engine settings associated with the engine. The computer implemented process 
includes the step of providing an engine management function interfacing with 
the program specific API. The engine management function furnishes a 
protective wrapper for each function call associated with the engine, trapping 
errors, and provides error management and administration to prevent conditions 
associated with improper engine functioning. The process optionally includes 
the step of providing an engine configuration function transforming API calls 
received from the program specific API into standardized calls. The engine 
configuration function provides additional functionality, including safely 
loading and unloading the engine. The process optionally includes the step of 
providing an engine function managing the standardized calls for each engine, 
thereby providing substantially uniform access to the engine and the engine 
settings associated with the engine. 



11/17/2003, EAST Version: 1.4.1 



Brief Summary Text - BSTX (46): 

In accordance with another embodiment of the invention, a computer 
implemented method migrates at least one program specific Application 
Programmer Interface (API) from an original state into a generic interface by 
building an object for each engine. The object provides substantially uniform 
access to the engine and engine settings associated with the engine. The 
computer implemented method includes the steps of defining a substantially 
consistent interface for individual object components that represent diverse 
technologies, and migrating a plurality of engines to the consistent interface. 
The computer implemented method also includes the step of substantially 
automatically and/or substantially uniformly, managing the individual object 
components using a predefined object manager and the consistent interface. 



Brief Summary Text - BSTX (47): 

In accordance with another embodiment of the invention, a computer 
architecture migrates at least one program specific Application Programmer 
Interface (API) from an original state into a generic interface by building an 
object for each engine. The object provides substantially uniform access to 
the engine and engine settings associated with the engine. The computer 
architecture includes an engine management layer interfacing with the program 
specific API and providing engine management and administration, an engine 
configuration layer transforming API calls received from the program specific 
API into standardized calls, and an engine layer managing the standardized 
calls for each engine. 



Brief Summary Text - BSTX (48): 

In accordance with another embodiment of the invention, an engine management 
layer configures a computer architecture to perform one or more computer 
implemented or computer assisted operations. The computer operations include 
one or more of loading and unloading engine dynamic link libraries into and out 
of memory for each engine, mapping at least one engine function to at least one 
corresponding engine object providing general error detection and error 
correction for each engine, determining and matching arguments and returning 
values for mapping the at least one engine function to the at least one 
corresponding engine object, and/or managing error feedback from the at least 
one program specific API. 



Brief Summary Text - BSTX (49): 

In accordance with another embodiment of the invention, a distributed 
computer system migrates a program specific Application Programmer Interface 
(API) from an original state into a generic interface by building an object for 
each engine. The object provides substantially uniform access to the engine 
and engine settings associated with the engine. The distributed computer 
system includes a server configured to include at least one engine having an 
engine interface providing one or more features to be executed, and at least 
one engine component configured to execute the one or more features of the 
engine by mapping a substantially consistent interface to the engine interface 
of the engine. The distributed computer system also includes at least one 
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client configured to be connectable to the server and optionally configured to 
be connectable to another server. The client includes an object manager layer 
communicable with and managing the at least one engine component stored on the 
server via the substantially consistent interface. 



Brief Summary Text - BSTX (50): 

In accordance with another embodiment of the invention, a distributed 
computer implemented process migrates a program specific Application Programmer 
Interface (API) from an original state into a generic interface by building an 
object for each engine. The object provides substantially uniform access to 
the engine and engine settings associated with the engine. The computer 
implemented process includes the step of providing, on a server, at least one 
engine having an engine interface, and providing one or more features to be 
executed. The computer implemented process also includes the step of 
providing, on at least one of the server and another server connectable to the 
server, at least one engine component configured to execute the one or more 
features of the engine by mapping a substantially consistent interface to the 
engine interface of the engine. The computer implemented process also includes 
the step of providing, on a client configured to be connectable to the server 
and optionally configured to be connectable to the another server, an object 
manager layer communicable with and managing the at least one engine component 
via the substantially consistent interface. 



Brief Summary Text - BSTX (53): 

In accordance with another embodiment of the invention, a computer readable 
tangible medium is provided that stores an object thereon, for execution by the 
computer. 



Brief Summary Text - BSTX (54): 

These together with other objects and advantages which will be subsequently 
apparent, reside in the details of construction and operation as more fully 
herein described and claimed, with reference being had to the accompanying 
drawings forming a part hereof wherein like numerals refer to like elements 
throughout. 



Drawing Description Text - DRTX (5): 

FIG. 4 is an illustration of the design of an Object in accordance with the 
computer architecture of the present invention; 



Detailed Description Text - DETX (29): 

A simplified overview of the architecture is illustrated in FIG. 3. In FIG. 
3, the component interface 8 sits on top of an Object Manager 14 that 
communicates with individual objects e.g., 16, 18, 20. These objects 16, 18, 
20 represent specific core technologies that are represented as "C"-level APIs. 
The design of Object!, Obiect2. . . . ObiectN is illustrated in FIG. 4. 



Detailed Description Text - DETX (35): 
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The architecture consists of a hierarchical series of layers that take any 
"C H -level API from its unique state to one that is standard and consistent. 
The result is a single, highly-integrated object component that contains and 
manages any type of engine that can be programmed regardless of the nature and 
subject of the core technology. The architecture therefore not only defines 
the goal (e.g., the object component interface) but also the means of 
implementing that goal for any type of engine. 



Detailed Description Text - DETX (36): 

The architecture is comprised of two major parts as illustrated in FIG. 5: 
the Object Manager 14, and the individual object components 16. 18,20. The 
Object Manager 14 in FIG. 5 manages individual object components 16, 18, 20 
illustrated as Object 1 , Object 2, etc. The Object Manager 14 communicates with 
the individual object components 16, 18, 20 using a consistent COM interface. 



Detailed Description Text - DETX (37): 

Each object component implements the feature set of an individual engine by 
mapping a consistent COM interface to the "C"-Level API interface of the 
individual engine that it supports. In this way the Object Manager can 
consistently communicate with each engine, using the engine's object component. 
Because the COM interface of each object component is consistent, the Object 
Manager can interface with every underlying engine the same way. 



Detailed Description Text - DETX (39): 

1) definition of consistent COM interfaces for individual object components 
that represent diverse technologies; 



Detailed Description Text - DETX (41): 

3) a predefined Object Manager that automatically manages the individual 
object components. 



Detailed Description Text - DETX (42): 

When implemented, for example, as an ActiveX control, the architecture also 
yields an umbrella control that can be used by a high-level programmer to 
program and manage numerous sophisticated technologies in a plug-and-play 
environment. In order to facilitate the discussion of the architecture itself 
it is best to start with the architecture of the engine object component and 
then describe the Object Manager. Since the Object Manager is directly 
dependent on the engine object components, an understanding of the latter will 
assist in the description of the former. 



Detailed Description Text - DETX (43): 
Engine Object Component--16, 18, 20 



Detailed Description Text - DETX (44): 
The purpose of the engine object is to wrap a specific engine using a series 
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of layers that convert the engine's unique interface into a COM interface that 
is, for example, specified by the architecture. The architecture not only 
defines the consistent COM interface for implementing an engine, it also 
describes how to implement the interface from the original "C"-Level API. Once 
the COM interface of the engine object component is implemented, the Object 
Manager understands and can therefore communicate with it. 



Detailed Description Text - DETX (45): 

Each engine component consists of, for example, three layers that are 
designed to migrate the original API of the engine to a consistent COM 
interface. As illustrated in FIG. 6, the Object Manager 14 communicates with 
the topmost layer 22 of the object component 16, 18, 20 which is the defined 
interface of object component. 



Detailed Description Text - DETX (46): 

Each layer is described below in two parts. The first part is the 
prescribed COM interface for communicating with the engine object component. 
The second part describes a specific path for automating building the layer. 
By providing an outline for automating building each layer, the overall engine 
object component can be automatically, substantially automatically or manually 
expedited and generated. 



Detailed Description Text - DETX (48): 

The first layer in the object component architecture is designed to deal 
with the fundamental features of an engine. This includes the ability to load 
and unload the standard or commercially available via, for example, Microsoft 
Corporation, engine Dynamic Link Libraries (DLLs) into memory, as well as the 
ability to consistently deal with errors. This is the most fundamental layer 
because it is the essential "wrapper" layer of an engine. Once this layer is 
complete all interaction with the underlying engine is filtered through this 
layer. Additional important engine management functions include dynamically 
accessing a function call of an engine, and initializing engine settings. All 
of these engine management functions are optionally and beneficially table 
driven to promote or facilitate access to, and implementation of, engine 
management functions. 



Detailed Description Text - DETX (55): 

The lEngineManagement interface is implemented in the C++ class as the 
public methods: ActivateEngine( ) and lsEngineActivated( ). 



Detailed Description Text - DETX (56): 

The first step of implementing the Engine Management layer 20 is to wrap 
each original engine function within a class- defined function that represents 
the original. For example, if there is an original function called 
Somefunction( ), then the engine object should have a corresponding 
Somefunction( ) method. The engine object version can then add standard engine 
and error management code so that any layers above have automatic error 
detection, correction, and reporting. 
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Detailed Description Text - DETX (58): 

Given the original function name, the GetProcAddress can map the original 
function to one that is defined by the engine object . Using the engine object 
C++ header file described above, the Somefunction( ) method is mapped to the 
original engine function using the following line of code: 



Detailed Description Text - DETX (59): 

To map all the function calls within the original engine DLLs just requires 
cycling through each function call and mapping it to the engine object 
counterpart. Since Windows contains facilities that enables access to all the 
functions within a DLL, a simple loop may be used. The hLib module is derived 
from the DLL name, which, as mentioned at the start, is the one piece of 
information we are given. 



Detailed Description Text - DETX (60): 

What is more complex is to define a generic implementation of the engine 
object version of the original function. This may be described in code as 
follows: 



Detailed Description Text - DETX (61): 

The engine object version of the original function passes the function call 
to the original one after completing a series of assertion tests, and is 
followed by a series of error detection tests. In this way the original engine 
function is "wrapped" by the engine object to manage error detection and 
correction. 



Detailed Description Text - DETX (63): 

The Load DLLs function is a generic implementation of a function that loops 
through the names of DLLs that are provided (in the form of the mJVIodules 
variable), and cycles through each one loading it into memory using the Windows 
LoadLibrary( ) function. A similar engine object function can be implemented 
to remove these DLLs from memory. 



Detailed Description Text - DETX (69): 
Mapping original functions to engine object counterparts 



Detailed Description Text - DETX (71): 

Determining and matching arguments and return values for mapping the 
original functions to their engine object counterparts. In order to add 
assertion and error detection and correction, the original function must be 
wrapped and called from within the engine object version of the original 
function. 



Detailed Description Text - DETX (72): 
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Managing error feedback. All APIs have their own way of providing error 
feedback. Since one of the goals of the Engine Management layer is to 
genetically manage error detection, correction, and feedback, it must handle 
all errors identically. However, APIs have numerous and incompatible methods 
in this case. I have determined that most APIs follow one of several distinct 
mechanisms for providing error feedback. By creating specific classes of APIs, 
the process of generating Layer 1 engine management may be expedited, manually 
and/or automatically. 



Detailed Description Text - DETX (74): 

The second layer 24 in the object component architecture is designed to deal 
with configuring an engine. This includes the ability to set any variety of 
features that are generally associated with the functioning of an engine. The 
architecture is designed to meet the challenge of providing a uniform interface 
for dealing with generally any or most engine settings. 



Detailed Description Text - DETX (75): 

The engine configuration layer 24 includes a series of prefabricated 
functions that map out the settings stored in the table to the appropriate 
engine configuration parameters. Accordingly, all that is needed is to fill in 
the values for the table associated with engine configuration. Thus, the 
engine object may advantageously come pre-packaged with predetermined tables 
populated with predetermined values. 



Detailed Description Text - DETX (86): 

The third layer 22 in the object component architecture is designed to deal 
with accessing the actual functionality of the core engine. For example, for 
an OCR engine this would be to OCR an image or a document. For a text 
retrieval engine this would be to initiate and retrieve results of a text 
search. 



Detailed Description Text - DETX (121): 

On top of these, a three-level C++ class (or object) 1 02 is built for each 
engine. This object gives uniform access to the engine and to all its unique 
settings. The three levels do the following: 



Detailed Description Text - DETX (122): 

Level 1 of the C++ classes 1 12 is a protective wrapper for each function 
call in the underlying engine. It traps all errors and provides error 
management and administration to prevent accidental GPFs or engine crashes. 



Detailed Description Text - DETX (123): 

Think of it as the "condom layer." While providing the most direct access 
feasible to the underlying engine and all its capabilities, level 1 of the C++ 
class 112 also protects the user from the engine. It manages all engine 
loading and unloading, prevents multiple copies of an engine and calls engines 
automatically as needed. 
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Detailed Description Text - DETX (125): 

Level 2 of the C++ classes 1 1 4 bridges the low-level API calls so they can 
be used by level 3 1 16 in standardized calls for each category. And it 
supplements the engine by providing additional functionality, such as safely 
loading and unloading engines. 



Detailed Description Text - DETX (126): 

Level 3 of the C++ class 116 consists of a standardized set of calls for all 
engines in each category. Programmers can access all the unique functions of 
each engine in a uniform way. 



Detailed Description Text - DETX (127): 

Another associated C++ class, called a Visual Class 104. adds a visual 
interpretation of each engine. This class manages all user interaction with 
each underlying engine. Like their lower-level counterparts, the Visual Class 
consists of three layers: 

Detailed Description Text - DETX (130): 

Level 3-122 manages anything else from the underlying engine (such as 
annotations) that needs to appear on the window. The Visual Class includes 
engine-specific Windows dialog boxes that let you customize which engine 
features you want to use, as well as any other Windows representation necessary 
for a toolkit. (For example, a compression engine has to display the 
image-the visual class, not the engine, does the work.) 



Detailed Description Text - DETX (131): 

The Object Manager layer 106, the first horizontal umbrella, orchestrates 
the underlying objects . It translates service requests into a form that the 
engine objects can understand. 



Detailed Description Text - DETX (132): 

The Windows Manager 108 presents Windows messages (move window, 
mouse/scrollbar/toolbox activity) to the Object Manager. It is written using 
Microsoft's Foundation Class (MFC), which makes it easy to support OCXs. (The 
OCX is in fact an MFC class.) 



Detailed Description Text - DETX (134): 

Accordingly, the present invention provides two main layers, the engine 
object component layer and the object manager layer. By creating these two 
main layers, the present invention allows third parties to create their own 
engine object component layers so that the third party engine can be readily 
compatible and useable by the present invention. In addition, the present 
invention is accessible via the Internet. That is, the present invention is 
operable over the Internet using, for example, standard Internet protocols, 
such as component object module (COM) communication protocol and distributed 
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(§) 

COM (DCOM) protocol. 



Detailed Description Text - DETX (135): 

In addition, the present invention optionally combines three layers of 
functions including the visual interface, the windows manager and the object 
manager into one layer called the object manager. Of course, this combination 
of layers is not meant to convey that only these specific layers must be used, 
but rather, to be indicative of overall functionality generally required to 
implement or execute component engines. That is, one or more of the above 
functions may be incorporated into the object manager layer. The present 
invention also advantageously combines the visual classes and C++ classes into 
the engine object component to further standardize and/or provide access to the 
object manager for engine object components. 



Detailed Description Text - DETX (136): 

The present invention optionally uses the standard ActiveX component control 
supplied, for example, by Microsoft Corporation. ActiveX is a protocol for 
component communication. The present invention also creates each of the object 
manager and the engine component layer as a separate ActiveX. That is, the 
object manager is its own ActiveX control, and the engine object is its own 
ActiveX control. Thus, the engine object can now run independently from the 
object manager. Accordingly, the engine object can operate without relying 
necessarily on the concurrent operation of the object manager. 



Detailed Description Text - DETX (137): 

The independent relationship between the engine object and the object 
manager means also that the engine object represents a discrete means of 
technology. For example, an engine object can be an OCR technology. This 
provides several benefits. First, because the object manager layer is open, 
the manufacturer of the OCR technology can wrap their own engine in the form of 
an engine object component, and the engine will automatically "plug into" or 
work with, the object manager. Thus, the engine object is provided high level 
access, making it accessible to many more parties, users, and the like. When 
the object manager interface is designed to be open, any third party, such as 
an engine manufacturer, can create their own engine object component that is 
compatible with the object manager, the manufacturer can do it. 



Detailed Description Text - DETX (138): 

FIG. 19 is an illustration of a distributed environment or architecture for 
manually and/or automatically generating and/or using reusable software 
components for client server and/or intranet operating environments. A very 
significant point that is relevant to why the object manager and the engine 
object component are independent in the present invention relates to providing 
a distributed environment for using the present invention. Rather than 
communicate within the same technology between the object manager and the 
engine object, the object manager and the engine object component communicate 
with each other in binary mode, via, for example, standard distributed 
component object module (DCOM) communication. As illustrated in FIG. 19, 
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object manager 14 communicates with engine object component 16, 18, 20 via DCOM 
specification 166. Other types of component communication may also be utilized 
that provide the capability of a distributed component interaction. 



Detailed Description Text - DETX (139): 

Thus, the engine object component and the object manager can leverage 
current protocols to not only communicate on the same machine, but also on 
different machines such as a client server and/or intranet and/or Internet 
environment. The object manager can be placed on one machine, and the engine 
object component on another machine and have distributed processing, what is 
otherwise called thin client processing, distributed processing, wide area 
intranet processing. 



Detailed Description Text - DETX (140): 

What this allows the present invention to do is to put the object manager on 
the thin client, who would accept the request from the user, for example, to 
OCR something or to print something. The actual request is handled or 
processed by the engine object component which generally resides on the server. 
The engine object component contains the horse power, or the processing power 
to process the request. 



Detailed Description Text - DETX (141): 

The engine object layer is generally located in the same or substantially 
same location as where the core technology or engine itself is being stored. 
Alternatively, the engine object layer and the engine may be optionally located 
in a distributed environment on different machines, servers, and the like. 



Detailed Description Text - DETX (142): 

FIG. 20 is a detailed illustration of the distributed environment or 
architecture for manually and/or automatically generating and/or using reusable 
software components for client server and/or intranet operating environments. 
In FIG. 20, client 170 includes object manager layer 172. Client 170 executes 
the core technology 180, via accessing engine object layer 178 managed/stored 
on server 176, and communicated via server 174. 



Detailed Description Text - DETX (143): 

Client 182, located on the same server 176 as core technology 180 and engine 
object layer 178, may also be used to execute the core technology 180 via 
object manager layer 184. In this instance, the client 182 with the object 
manager layer 184 is located on the same server 176 as the engine object layer 
178. In addition, since the present invention utilizes a communication 
protocol between components, for example, DCOM, that allows a client to also 
include both the engine object component layer and the object manager layer on 
the same machine 186, as well as the core technology. 



Detailed Description Text - DETX (144): 
Further, since the object manager is formatted or constructed of a client 
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technology, the object manager can sit in a standard browser. This means that 
anyone that has an Internet browser, i.e., anyone that has access to the world 
wide web (WEB) can actually access the core engine technology. Thus, by 
structuring the architecture of the present invention as described herein, 
users automatically become Internet, intranet and/or WEB enabled. 



Detailed Description Text - DETX (145): 

The present invention also transforms the core technology from essentially 
client based technology into a client server and/or a thin client technology. 
This makes the core technology high level accessible, thereby transforming any 
core technology into client server, or hidden client technology. The browser 
is located on the client, and the browser leverages the object manager. 
Accordingly, the browser optionally contains the object manager, and the object 
manager makes requests over, for example, the Internet, local network, and the 
like via a server, to the engine object . The server would be either a web 
server or a LAN server. 



Detailed Description Text - DETX (146): 

The present invention also advantageously provides the ability to have the 
client and the server, in a distributed environment as discussed above, or on 
the same machine locally. The present invention utilizes the DCOM 
communication protocol defining the communication protocol between the object 
manager and the engine object component. Accordingly, since DCOM can work on 
the same machine as well as in a distributed environment, DCOM does not 
necessitate that the engine object or the object manager component be on two 
separate machines. 



Detailed Description Text - DETX (147): 

FIG. 21 is an illustration of a distributed environment or architecture for 
manually and/or automatically generating and/or using reusable software 
components for network environments, such as the Internet. As illustrated in 
FIG. 21 , object manager 14 communicates with engine object component 16, 18, 20 
via DCOM specification and a networking environment, such as the Internet, 
intranet, and the like 168. Other types of component communication may also be 
utilized that provide the capability of a distributed component interaction 
over a networking environment. 



Detailed Description Text - DETX (148): 

FIG. 22 is a detailed illustration of the distributed environment or 
architecture for manually and/or automatically generating and/or using reusable 
software components in the Internet environment. In FIG. 22, client 170 
includes object manager layer 1 72. Browser/thin client 1 70 a executes the core 
technology 180, via accessing engine object layer 178 managed/stored on web 
server 176a, and communicated via the Internet 174a. 



Detailed Description Text - DETX (149): 

Browser/thin client 182a, located on the same web server 176a as core 
technology 180 and engine object layer 178, may also be used to execute the 
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core technology 180 via object manager layer 184. In this instance, the 
browser/thin client 182a with the object manager layer 184 is located on the 
same web server 176a as the engine object layer 178. In addition, since the 
present invention utilizes a communication protocol between components, for 
example, DCOM, that allows a client to also include both the engine object 
component layer and the object manager layer on the same machine 186, as well 
as the core technology. 



Detailed Description Text - DETX (154): 

FIG. 24 is an illustration of a stand-alone and/or distributed environment 
or architecture for image viewer in client server and/or intranet operating 
environments. The architecture in FIG. 24 provides the capability to perform 
the viewer process off-line. That is, the viewer process 188 provides an added 
feature on top of the object manager layer 14. As described above, object 
manager layer 14 is essentially an interface, and the viewer process 188 is an 
application that leverages the object manager layer 14. 



Detailed Description Text - DETX (155): 

The advantage of the viewer process 188 being built on the object manager 
layer 14, which is built on top of the engine object layer 16, 18, 20, is that 
the viewer process can offset its processing capabilities anywhere in a 
distributed environment. It can have the processing occur at the local 
station, on a server, and the like, as described below in detail. 
Significantly, the object manager and the engine object component are 
independent to provide a distributed environment for using the present 
invention. Rather than communicate within the same technology between the 
object manager and the engine object, the object manager and the engine object 
component communicate with each other in binary mode, via, for example, 
standard distributed component object module (DCOM) communication. 



Detailed Description Text - DETX (156): 

As illustrated in FIG. 24, object manager 14 communicates with engine object 
component 16, 18, 20 via DCOM specification 166. Other types of component 
communication may also be utilized that provide the capability of a distributed 
component interaction. Object manager 14 is also respectively connectable to 
viewer process 188. 



Detailed Description Text - DETX (157): 

Thus, the engine object component and the object manager can leverage 
current protocols to not only communicate on the same machine, but also on 
different machines such as a client server and/or intranet and/or Internet 
environment. The object manager and/or viewer process can be placed on one 
machine, and the engine object component on another machine and have 
distributed processing, what is otherwise called thin client processing, 
distributed processing, wide area intranet processing. 



Detailed Description Text - DETX (158): 
What this allows the present invention to do is to put the object manager on 
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the thin client, who would accept the request from the user, for example, to 
perform the viewer process. The actual request is handled or processed by the 
engine object component which generally resides on the server. The engine 
object component contains the horse power, or the processing power to process 
the request. 



Detailed Description Text - DETX (159): 

The engine object layer is generally located in the same or substantially 
same location as where the core technology or engine itself is being stored. 
Alternatively, the engine object layer and the engine may be optionally located 
in a distributed environment on different machines, servers, and the like. 



Detailed Description Text - DETX (160): 

FIG. 25 is a detailed illustration of a stand-alone and/or distributed 
environment or architecture for image viewer in client server and/or intranet 
operating environments. In FIG. 25, client 170 includes object manager layer 
172 with viewer process 192. Client 170 executes the core technology 180, via 
accessing engine object layer 178 managed/stored on server 176, and 
communicated via server 174. Viewer process 190 is also optionally available 
to either or both servers 174, 176. 



Detailed Description Text - DETX (161): 

Client 182, located on the same server 176 as core technology 1 80 and engine 
object layer 178, may also be used to execute the core technology 180 and/or 
viewer process 1 92 via object manager layer 1 84. In this instance, the client 
182 with the object manager layer 184 is located on the same server 176 as the 
engine object layer 178. In addition, since the present invention utilizes a 
communication protocol between components, for example, DCOM, that allows a 
client to also include both the engine object component layer, viewer process 
194 and the object manager layer on the same machine 186, as well as the core 
technology. 



Detailed Description Text - DETX (162): 

Further, since the object manager is formatted or constructed of a client 
technology, the object manager can sit in a standard browser. This means that 
anyone that has an Internet browser, i.e., anyone that has access to the world 
wide web (WEB) can actually access the core engine technology and/or viewer 
process. Thus, by structuring the architecture of the present invention as 
described herein, users automatically become Internet, intranet and/or WEB 
enabled. 



Detailed Description Text - DETX (163): 

The present invention also transforms the core technology and/or viewer 
process from essentially client based technology into a client server and/or a 
thin client technology. This makes the core technology high level and/or 
viewer process accessible, thereby transforming any core technology and./or 
viewer process into client server, or hidden client technology. The browser is 
located on the client, and the browser leverages the object manager. 



11/17/2003, EAST Version: 1.4.1 



Accordingly, the browser optionally contains the object manager, and the object 
manager makes requests over, for example, the Internet, local network, and the 
like via a server, to the engine object . The server would be either a web 
server or a LAN server. 



Detailed Description Text - DETX (164): 

The present invention also advantageously provides the ability to have the 
client and the server, in a distributed environment as discussed above, or on 
the same machine locally. The present invention utilizes the DCOM 
communication protocol defining the communication protocol between the object 
manager and the engine object component. Accordingly, since DCOM can work on 
the same machine as well as in a distributed environment, DCOM does not 
necessitate that the engine object or the object manager component be on two 
separate machines. 



Detailed Description Text - DETX (165): 

FIG. 26 is an illustration of a stand-alone and/or distributed environment 
or architecture for image viewer in network environments, such as the Internet. 
As illustrated in FIG. 21 , object manager 14 communicates with engine object 
component 16, 18, 20 via DCOM specification and a networking environment, such 
as the Internet, intranet, and the like 168. In addition, object manager layer 
14 also advantageously communications with viewer process 188a. Other types of 
component communication may also be utilized that provide the capability of a 
distributed component interaction over a networking environment. 



Detailed Description Text - DETX (166): 

FIG. 27 is a detailed illustration of a stand-alone and/or distributed 
environment or architecture for image viewer in the Internet environment. In 
FIG. 27, client 170 includes object manager layer 172. Browser/thin client 
170a executes the core technology 1 80 and/or viewer process 192a, via accessing 
engine object layer 178 managed/stored on web server 176a, and communicated via 
the Internet 174a. Viewer process 190 is also optionally available to web 
server 176a. 



Detailed Description Text - DETX (167): 

Browser/thin client 182a, located on the same web server 176a as core 
technology 180, viewer process 192a and engine object layer 178, may also be 
used to execute the core technology 180 via object manager layer 184. In this 
instance, the browser/thin client 182a with the object manager layer 184 is 
located on the same web server 176a as the engine object layer 178. In 
addition, since the present invention utilizes a communication protocol between 
components, for example, DCOM, that allows a client to also include both the 
engine object component layer and the object manager layer on the same machine 
186, as well as the core technology and viewer process. 



Detailed Description Text - DETX (170): 

Further, as indicated herein, the present invention may be used to automate 
and/or manually expedite the migration of a program specific Application 
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Programmer Interface from an original state into a generic interface by 
building an object for each engine. The object advantageously provides 
substantially uniform access to the engine and engine settings associated with 
the engine. The present invention may be applied across a broad range of 
programming languages that utilize similar concepts as described herein. 



Detailed Description Paragraph Table - DETL (1): 

class SomeEnqineQbiect [ //Wrapper Functions private: 
FARPROC_SomeFunction; BOOL SomeFunction. oval-hollow.; //EngineManagement 
protected: BOOL GetProcAddress (HINSTANCE, FARPROC&, LPCTSTR); BOOL 
GetProcAddresses.oval-hollow.; BOOL ProcessError. oval-hollow.; public: BOOL 
ActivateEngine (BOOL Activate); BOOL IsEngineActivated. oval-hollow.; ]; 



Claims Text- CLTX (1): 

1 . A distributed computer implemented process for migrating at least one 
program specific Application Programmer Interface (API) from an original state 
into a substantially consistent interface by building an object for at least 
one of an engine and a viewer process, the object providing substantially 
uniform access to the at least one of the engine having engine settings and the 
viewer process, comprising the steps of: 



Claims Text -CLTX (4): 

(c) providing, on a client configured to be connectable to the server and 
optionally configured to be connectable to the another server, an object 
manager layer communicable with and managing the at least one engine component 
or the another viewer process via the substantially consistent interface. 



Claims Text- CLTX (5): 

2. A distributed computer implemented process according to claim 1 , wherein 
the object manager layer is consistently communicable with each engine or the 
viewer process using the at least one engine component via the substantially 
consistent interface. 



Claims Text- CLTX (6): 

3. A distributed computer implemented process according to claim 1 , wherein 
the substantially consistent interface comprises at least one of a component 
object module (COM) communication protocol and a distributed COM (DCOM) 
protocol. 



Claims Text - CLTX (9): 

6. A distributed computer implemented process according to claim 5, wherein 
the binary mode communication protocol includes a distributed component object 
module (DCOM) protocol. 



Claims Text -CLTX (10): 
7. A distributed computer implemented process according to claim 5, wherein 
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the binary mode communication protocol provides the capability for the engine 
component to execute independent of the object manager layer. 



Claims Text- CLTX (12): 

9. A distributed computer system for migrating at least one program 
specific Application Programmer Interface (API) from an original state into a 
substantially consistent interface by building an object for at least one of an 
engine and a viewer process, the object providing substantially uniform access 
to the at least one of the engine having engine settings and the viewer 
process, comprising: 



Claims Text- CLTX (16): 

a client configured to be connectable to said server and optionally 
configured to be connectable to another server, said client including an object 
manager layer communicable with and managing the at least one engine component 
or the another viewer process via the substantially consistent interface. 



Claims Text -CLTX (17): 

10. A distributed computer system according to claim 9, wherein the object 
manager layer is consistently communicable with each engine using the at least 
one engine component via the substantially consistent interface. 



Claims Text -CLTX (18): 

1 1. A distributed computer system according to claim 9, wherein the 
substantially consistent interface comprises at least one of a component object 
module (COM) protocol and a distributed COM (DCOM) protocol. 



Claims Text- CLTX (21): 

14. A distributed computer system according to claim 13, wherein the binary 
mode communication protocol includes a distributed component object module 
(DCOM) protocol. 



Claims Text- CLTX (29): 

17. A distributed computer implemented process including an object 
providing substantially uniform access to at least one engine having engine 
settings associated with the engine and an engine interface for accessing the 
engine settings and one or more features to be executed, comprising the steps 
of: 



Claims Text -CLTX (31): 

(b) providing, on a client configured to be connectable to the server and 
optionally configured to be connectable to the another server, an object 
manager layer communicable with and managing the at least one engine component 
via the substantially consistent interface. 
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Claims Text- CLTX (36): 

a client configured to be connectable to said server and optionally 
configured to be connectable to another server, said client including an object 
manager layer communicable with and managing the at least one engine component 
stored on said server via the substantially consistent interface. 



Claims Text- CLTX (39): 

(b) mapping at least one engine function to at least one corresponding 
engine object : 



Claims Text- CLTX (41): 

(d) determining and matching arguments and returning values for mapping the 
at least one engine function to the at least one corresponding engine object : 
and 



Claims Text- CLTX (43): 

20. A computer implemented method utilizing a substantially consistent 
interface for individual object components that represent diverse technologies, 
comprising the steps of: 



Claims Text- CLTX (45): 

(b) at least one of substantially automatically and substantially uniformly, 
managing the individual object components using a predefined object manager and 
the consistent interface. 



Claims Text - CLTX (50): 

22. A distributed computer implemented process including an object 
providing substantially uniform access to at least one engine having engine 
settings associated with the engine and an engine interface for accessing the 
engine settings and one or more features to be executed, comprising the steps 
of: 



Claims Text - CLTX (52): 

(b) managing, on a client configured to be connectable to the server and 
optionally configured to be connectable to the another server, an object 
manager layer to manage the at least one engine component via the substantially 
consistent interface. 
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Drawing Description Text - DRTX (8): 

FIG. 6 is a block diagram of the persistent objects comprising the system 
objects 122 (FIG. 1) in accordance with one possible relational embodiment of 
the present invention; 



Drawing Description Text - DRTX (9): 

FIGS. 7A and 7B are block diagrams of the persistent objects comprising the 
client objects 124 (FIG. 1) in accordance with one possible relational 
embodiment of the present invention; 



Detailed Description Text - DETX (4): 

The first tier is the data storage tier 110, which handles persistent 
storage of information through one or more databases 112 and 1 14. The second 
tier is the object tier 120, which captures and converts row data from the data 
storage tier 1 10 to objects and then executes business rules against the 
objects . The third tier is the user interface tier 140, which presents raw 
and/or object data to the system user via the display 104 and receives commands 
and data from the system user via the keyboard 106. These three tiers 1 10, 120 
and 140 are "logical" because they are not confined to a single machine or 
process. Accordingly and as illustrated in FIG. 5, each of the tiers 1 10, 120 
or 140 may simultaneously span many physical machines and processes across one 
or more networks. 



Detailed Description Text - DETX (8): 

The object tier 120 is divided into two distinct subsystems: system objects 
and processes 122, which control system operation and administrative functions; 
and client objects and processes 124, which control all data operations on the 
marketing data. The system objects 122 are "persistent objects. " which are 
usually stored in the system database 1 12 and are instances of classes for 
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which a mapping is defined between the attributes of the class and columns in a 
database table. The values of the object attributes are stored in the database 
table through this mapping. 



Detailed Description Text - DETX (9): 

The object tier 120 may also include EOFLite components 126 to provide a 
"lightweight" binding layer for moving data back and forth between the client 
database 114 and minions 128 executing high-volume "batch processes." The 
EOFLite components 126 create instances of custom classes without having to 
live with the overhead inherent in the lower-level EOF frameworks, which are 
designed more for OLTP-type processing than for record-by-record batch 
processing. 



Detailed Description Text - DETX (10): 

Both the system objects 122 and the client objects 124 use persistent object 
classes to define specific business logic that is associated with the object 
attributes (and therefore implicitly with data from the databases 112 and 114 
through the attribute-to-table-column mapping). Persistent objects can be 
instantiated from an arbitrary combination of database columns into "generic 
records," or can be instances of pre-defined classes containing attributes that 
are associated with particular columns in a table. Whether instances of 
generic records or instances of pre-defined classes are built is determined by 
the attribute-to-table mapping. In either case, the instances are created 
through a "database access layer." and made available to custom processes that 
can observe, manipulate, and save the instances back to the database. 



Detailed Description Text - DETX (1 1): 

The object tier 120 also contains minions 128, which provide services and 
sets of persistent objects to external client objects . In any given 
installation of the present invention, these objects can exist in both 
client-side end-user applications and in "interface-free" server-side 
applications called "agents." The agents exist to provide an executable wrapper 
around the minions 128. Thus, a particular agent can host an arbitrary 
combination of minions 128, and can be executed on any machine in a given 
installation of the present invention for which an executable has been built. 



Detailed Description Text - DETX (12): 

The minions 128 in these agent processes use the database access layer to 
convert database information between row form and persistent object form, and 
share these persistent objects with interface tier clients and/or other object 
tier clients. The minions 128 may also provide services that manipulate the 
objects locally and send the objects back to the database for storage. The 
minions 128 and persistent objects encapsulate business logic, and insulate the 
user applications 142 in the user interface tier 140 from data storage tier 110 
dependencies. Minions 128 can exist in either remote agent processes or in the 
local address space of a client process. Client processes can also receive 
persistent objects directly from the database access layer . 
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Detailed Description Text - DETX (13): 

There are two categories of minions 128 and persistent objects in the object 
tier 120. The first category consists of objects that oversee the control and 
administration functions of the present invention, such as the agent manager 
130, job queue manager 132, notification manager 134, security guard 136, 
session management (not shown), and resource tracking and manipulation (not 
shown). The second category of objects imports, exports, reports on, cleans, 
maintains, and represents client data. All agent processes in the object tier 
120 are controlled by a special minion called the "agent manager 130. All 
access to remote agents and minions is granted through the agent manager 130. 



Detailed Description Text - DETX (14): 

The object tier 120 can be implemented using OpenStep object technology. 
This technology provides a database-independent framework for gathering 
information from local and/or remote database servers and converting it to 
object form. This technology also provides a relatively transparent object 
distribution mechanism that allows objects to communicate with each other 
across process and network boundaries as easily as if the objects coexisted in 
the same process. These key features directly support the ability for 
processes in the object tier 120 to execute on multiple physical machines. 



Detailed Description Text - DETX (15): 

The user interface tier 140 receives object data from the object tier 120, 
and controls the presentation of this data to the user. The user application 
142 in the user interface tier 140 can operate in either two-tier or three-tier 
modes. User applications 142 that make direct connections to the database 
server to get data will be two-tier applications. User applications 1 42 that 
connect to agents in the object tier 120 to get data will be three-tier 
applications. It is possible for user applications 142 to directly include 
object tier classes and use them locally, operating in two-tier mode without 
actually bypassing the object tier 120. The user applications 142 may be 
implemented using native OpenStep applications, web-browser-based applications 
and applications built using technologies such as Microsoft Visual C++, which 
will communicate with the object tier via an object interface standard such as 
DCOM and CORBA. 



Detailed Description Text - DETX (16): 

Referring to FIG. 2, the basic anatomy of an agent process, in accordance 
with a preferred embodiment of the present invention, is designated generally 
by the numeral 150. The agent process 150 comprises a connection 152, an agent 
154, an agent profile 156 and one or more minions 158, 160 and 162. As 
described above, the processes running in the object tier 120 are called agents 
154, which are generic, independently executable programs that can run on any 
machine in the system. The sole purpose of an agent 154 is to serve as a 
distribution and control mechanism for an arbitrary combination of named class 
instances called minions 158, 160 and 162. The minions 158, 160 and 162 are 
objects that provide services and sets of persistent objects to external client 
objects through interfaces called minion formal protocols. There is a separate 
protocol defined for each possible minion class that needs to communicate 
across the network. Protocols are not classes, and are therefore never 
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instantiated or stored in a database. 



Detailed Description Text - DETX (17): 

Agents 154 do not inherently depend on the minions. During startup, an 
agent 154 extracts agent profile information 156 from a configuration file 
using a name given to it on the command line as a lookup key. The agent 
profile 156 specifies the minions 158, 160 and 162 that the agent 154 will 
manage, and any additional code that the agent 154 must load to support those 
objects . The agent process 150 configures itself dynamically based on the 
agent profile 156. 



Detailed Description Text - DETX (18): 

To support maximum flexibility on how systems can be configured, no 
restrictions are placed on where an agent 154 can execute (in other words, an 
agent 154 can be launched on any machine for which an agent executable has been 
built). This permits the logical object tier 120 (FIG. 1) to span the network 
across various physical machines concurrently. In practice, if agent 154 
and/or the minions 158, 160 and 162 managed by the agent 154 depend on 
resources on a particular machine, the agent 154 should be configured to 
execute on that machine to keep those resources "local." External clients may 
gain access to the agent 154 via the connection 152, which is registered under 
a unique name given on the command line when the agent process 150 is launched. 



Detailed Description Text - DETX (24): 

The minion interfaces are defined in this way to make local minion instances 
158, 160 and 162 and local minion proxy instances 188, 190 and 192 have the 
same apparent interface. The proxy classes provide a convenient place to 
perform client-side caching, a level of indirection through which to handle 
disconnection/reconnection with remote minions, and a class on the client side 
that can be associated with formal protocols. It also makes remote minions 
relatively transparent to developers. Client processes 182 that choose to use 
minions 158, 160 and 162 directly in their local address space operate in 
"two-tier" mode. Client processes 182 that choose to use minion proxies 188, 
190 and 192 in their local address space operate in "three-tier" mode. In 
either event, the client processes 182 will be able to send the same messages 
to either type of object . 



Detailed Description Text - DETX (25): 

"Formal Protocols" define formal interfaces that are independent of any 
particular class . A protocol has a unique name, and declares a set of messages 
that can be implemented by any class . A particular class "conforms" to one or 
more protocols if it guarantees that it implements every message declared in 
each of the protocols. The interface to the minion classes is defined entirely 
in terms of formal protocols. A given minion class and its corresponding 
minion proxy class will both conform to the same formal protocol. A unique 
formal protocol is defined for every minion subclass. 



Detailed Description Text - DETX (26): 



11/17/2003, EAST Version: 1.4.1 



Minion classes, minion proxy classes, and formal protocols are uniquely 
named to coexist in the same address space without interfering with each other. 
Client processes 182 can then simultaneously perform some operations in 
"two-tier" mode and others in "three-tier" mode depending on whichever is more 
appropriate. 



Detailed Description Text - DETX (28): 

Physical machine 202, having a keyboard 204, a monitor 206, a user interface 
tier 210 and a user application 212, is connected to a local area network 208. 
Physical machine 214, having a user interface tier 216, object tier 220 and 
data storage tier 222, is also connected to the network 208. The user 
application 212 of physical machine 202 is shown communicating with the agent 
manager 224 in the object tier 220 of physical machine 214. The agent manager 
224 in turn communicates with agents 226, which communicate with database 
processes 228 and databases 230 in data storage tier 222. 



Detailed Description Text - DETX (29): 

Physical machine 232, having an object tier 234 and data storage tier 236, 
is also connected to the network 208. The user application 212 of physical 
machine 202 is shown communicating with the agent manager 238 in the object 
tier 234 of physical machine 232. The agent manager 238 in turn communicates 
with agents 240, which communicate with database processes 242 and databases 
244 in data storage tier 236. The agents 240 of physical machine 232 are also 
shown communicating with the data storage tier 248, database processes 250 and 
databases 252 of physical machine 246 via the local area network 208. 



Detailed Description Text - DETX (30): 

Physical machine 254, having an object tier 256, is also connected to the 
network 208. The agent manager 258 and agents 260 of physical machine 254 are 
shown communicating with the database processes 242 of physical machine 232 and 
the database processes 250 of physical machine 246 via the local area network 
208. 



Detailed Description Text - DETX (36): 

For example, each minion has a name that is used by a client process to 
request a connection to a specific minion through the agent manager 1 30. When 
the agent manager 130 is asked for connection information to a named minion, it 
performs the following steps: (1) consults the cross-reference to determine the 
generic name of the agent(s) that would be hosting that object : (2) examines 
all idle running agents with that generic name (if any), and determines if any 
of them report that their minion of the requested name is idle; (3) if any such 
agents are found, their connection information is loaded into an agent ticket 
and returned to the client; (4) if no agents with that generic name are 
running, the agent manager will simply start one and use it in the returned 
agent ticket; (5) if there are running agents with that generic name but none 
of them are idle, the agent manager will consult the present invention's system 
configuration file to determine how many agents with that generic name can be 
running simultaneously, and start a new one if limits permit; and (6) if all of 
that fails, no connection information is returned to the client (the client 
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must be prepared to handle a connection refusal). 



Detailed Description Text - DETX (37): 

Client processes that need to connect to a particular agent (or to some 
named minion running in a particular agent) will go through the agent manager 
130 to get the information necessary to make the connection. This connection 
information is vended in the form of "agent tickets" (for connection to the 
agent itself) and " object tickets" (for connection to a minion), which can be 
"redeemed" by client objects to gain direct connections to remote agents and 
minions. Client processes must always get their connection information in 
"ticket" form through the agent manager 130. This is because the agent manager 
130 will usually be controlling more than one instance of an agent with a 
particular generic name, each of which will be registered with the object 
distribution mechanism under a unique name that is only known to the agent 
manager 130 and the agent itself. The single exception to this is for 
connections to the AgentManagerAgent, which will always register under the name 
"AgentManagerAgent". 



Detailed Description Text - DETX (43): 

The NotificationCenterMinion serves as a central hub for routing advisory 
notifications from objects that "post" the notifications, to an arbitrary 
number of objects that register as "observers" of the notifications. Each 
advisory message has a name, and is associated with an object and a set of 
supplementary "user information." The names of the notifications are determined 
by the posting objects, and have to be known to observers so they can register 
as observers of the notifications. The object and "user information" 
associated with the notifications are also determined by the posting object, 
and can be whatever is deemed important for any particular advisory 
notification. Only one notification center will run in a given system of the 
present invention. 



Detailed Description Text - DETX (45): 

The security guard 136 hosts the SecurityGuardMinion, which is the first 
line of defense in the object tier for protecting the system against 
unauthorized access. The SecurityGuardMinion determines the validity of a 
given user/ID and password combination, and determines if a user has permission 
to perform a specific action. All guarded operations will obtain permission 
from the security guard before proceeding. The security guard 136 will always 
run in a stand-alone process so that it can be given special privileges if 
necessary. The security guard 136 thus prevents users from: (1) intentionally 
and/or unintentionally manipulating data without proper authorization; (2) 
reading data without proper authorization; and (3) making invalid changes to 
data whether authorized or not. 



Detailed Description Text - DETX (46): 

Due to the importance of the data contained within the databases and the 
efforts expended to obtain that data, the database must be protected against 
unauthorized access, yet still allow the present invention to perform tasks on 
behalf of those same users. Security becomes more difficult in the multiple 
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machine, multiple database architecture of the present invention because a user 
can connect to a database in a variety of ways: (1) directly from a present 
invention front-end process; (2) indirectly from an object-tier process to the 
present invention; (3) directly on the server via an SQL tool such as Informix 
DBaccess or Oracle SQLplus; and (4) directly from an arbitrary front-end 
development tool (such as VisualFoxPro) via ODBC. 



Detailed Description Text - DETX (54): 

The RoboDBAAgent hosts the RoboDBAMinion, which controls manipulation of 
database objects . The RoboDBAMinion provides services for: creating and 
dropping tables; creating and dropping indexes; unloading table schemas; and 
loading and unloading table data. The RoboDBAMinion can be embedded in an 
agent process and scheduled for deferred execution by the job management 
system. The RoboDBAMinion can also be given special database privileges that 
are not provided to any other process because the minion can run in a separate 
agent process. The only kinds of database tables that will be created through 
this minion are temporary database tables called "project tables" that provide 
work areas while processing the data for particular projects. Client 
production tables will always be created by external scripts when setting up 
the present invention for new clients. 



Detailed Description Text - DETX (63): 

The EventLogMinon provides a central point of access for all advisory 
messages that need to be stored persistently in the database. The "events" in 
the log are descriptions of some event in time, such as the observed failure of 
a critical component, or the failure of a job stream to complete. The events 
stored in the log describe unusual conditions that require the attention of a 
user or system operator. Initial deployments of the present invention will 
include an event log object as a simple local convenience object in each 
application that needs to access the log, rather than have a single central 
event log that runs in a remote agent. 



Detailed Description Text - DETX (65): 

Now referring to FIG. 6, a block diagram of the persistent objects 
comprising the system objects 122 (FIG. 1), in accordance with one possible 
relational embodiment of the present invention, is illustrated. The present 
invention is not limited to the specific system objects 122 described or to the 
relational embodiment illustrated in FIG. 6. Those persons skilled in the art 
will recognize that the present invention is designed to allow system objects 
122 to be added, deleted or changed, and the relationships between the system 
objects 122 to be changed according to the intended application of the present 
invention. The relational nature of the system objects 122 allow the present 
invention to be modified without extensive recoding. 



Detailed Description Text - DETX (66): 

The system objects 122 comprise a number of interrelated persistent objects 
that are the object tier representation of rows in database tables. The 
persistent objects are grouped according to the minions that are primarily 
responsible for manipulating them. 
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Detailed Description Text - DETX (67): 
Billing Persistent Objects : 



Detailed Description Text - DETX (68): 

Activity objects 302 associate an accounting activity code with a 
description. In this regard these objects are very similar to the CodeMaster 
31 0 and CodeLook 312 is objects . Activity objects 302 are a separate class 
because they are closely associated with the accounting department, and are 
updated periodically with data obtained from the accounting system. The 
CodeMaster 310 and CodeLook 312 objects are relatively static and are 
associated exclusively with the present invention. 



Detailed Description Text - DETX (69): 

Billing objects 304 contain transaction information that is used to bill 
clients for services provided on their behalf. Billing objects 304 include 
such information as: an account number to bill against; tracking information 
about when the transaction occurred and when it was posted to the accounting 
department; a description of the services being billed; and billing units and 
amounts. Clients are billed for both processing storage and disk space usage. 
Billing objects 304 for processing are created at the end of process execution, 
whereas Billing objects 304 for disk storage are created on weekly intervals by 
the DiskUsageBillingAgent. A given Billing object 304 is associated with one 
MatterNum 308 and ClientBase 314 object . 



Detailed Description Text - DETX (70): 

BillinqSummarv objects 306 represent Billing objects 304 summarized over 
some period of time by client, project, matter number, and accounting activity 
code. These objects are created periodically by the BillingManagerMinion. 
Summarizing Billing objects 304 into BillinqSummarv objects 306 provides the 
accounting department with the minimum set of items needed to perform the 
required billing functions. 



Detailed Description Text - DETX (71): 

MatterNum objects 308 contain billing information and activity status for a 
particular ClientBase object 314. Typically, a ClientBase object 314 has a 
matter number for disk storage billing and a matter number for data processing 
billing. Project objects 316 also have a matter number for disk storage 
billing and a matter number for data processing billing. When a new Project 
object 316 is created for a given ClientBase object 314, the matter numbers for 
the single ClientBase object 314 are copied and associated with the new Project 
object 316. The matter numbers for the Project object 316 may be changed at 
anytime after the Project object 316 is first created. Billing records are 
associated with one matter number. 



Detailed Description Text - DETX (72): 
Job Management Persistent Objects : 
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Detailed Description Text - DETX (73): 

A JobConfig object 31 8 is a description of a process to be executed that may 
include: a text description of the job configuration; an identifier associating 
it with the process configuration object that was used to create the job 
configuration; the name of the agent to run; command line arguments to send to 
the agent when it is launched; the messages the agent must process; a 
description of any dependencies on other job configuration objects : tracking 
information about when the job configuration started and ended processing; and 
result information about the volume of records processed and success or failure 
of processing. A JobConfig object 318 is associated with one JobStream object 
322 and one ProcessConfig object 324. 



Detailed Description Text - DETX (74): 

A JobQueue object 320 associates a single JobStream object 322 with a date, 
time, and priority at which to run, and context information to use during 
execution. Once a JobQueue object 320 has been saved in the database, it can 
be modified or deleted. Deleting the JobQueue 320 entry removes the associated 
JobStream 322 and JobConfig 31 8 objects from the database. Modifications that 
can be made to the JobQueue object 320 include changing the date, time or 
priority. 



Detailed Description Text - DETX (75): 

A JobStream object 322 associates a group of JobConfig objects 31 8 together 
into a stream, where the JobConfig objects 318 can have dependencies between 
them. A JobStream object 322 is associated with one or more JobConfig objects 
318 and may include information such as a text description of the job stream, 
information about dependencies on other job streams, tracking information about 
when the job stream started and ended execution, control information about 
expected execution times, and job stream completion status information. 



Detailed Description Text - DETX (76): 

A ProcessConfig object 324 is a 'template" from which JobConfig objects 318 
are created. When a system user of the present invention wants to submit a new 
JobConfig object 318 to the system, an existing ProcessConfig object 324 can be 
used as a template, or a new ProcessConfig object 324 can be created. In 
either case the ProcessConfig object 324 is saved back to the database. 
ProcessConfig objects 324 are essentially JobConfig objects 318 without the 
dynamic attributes, but may include such information as a text description of 
the process configuration, the name of the agent to run, command line arguments 
to send to the agent when it is launched, the messages the agent must process, 
and a description of any dependencies on other job configuration objects . A 
ProcessConfig object 324 is associated with one ProcessStream object 326. A 
ProcessStream object 326 and its associated ProcessConfig objects 324 never 
become part of the job queue. Instead, when a user submits a JobStream object 
322 to the job queue for execution, the ProcessStream 326 and ProcessConfig 324 
objects are used to create JobStream 322 and JobConfig 318 objects: those are 
the objects actually submitted to the queue. 
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Detailed Description Text - DETX (77): 

A ProcessStream object 326 is a "template" from which JobStream objects 322 
are created. When a system user wants to submit a new JobStream object 322 to 
the system, an existing ProcessStream object 326 can be used as a template, or 
a new ProcessStream object 326 can be created. In either case, the 
ProcessStream object 326 is saved back to the database. ProcessStream objects 
326 are essentially JobStream objects 322 without the dynamic attributes, but 
may include such information as a text description of the job stream, and 
information about dependencies on other job streams. 



Detailed Description Text - DETX (78): 
Media Processing And Tracking Persistent Objects : 



Detailed Description Text - DETX (79): 

A CartridgeTape object (not shown) differs from basic Tapes in that it has 
compression and track count information associated with it. A given 
CartridgeTape object can be associated with one ClientBase object 314 (but a 
given ClientBase object 314 may be associated with many CartridgeTape objects, 
or more generally, with many other PhysicalMedia objects 332). 



Detailed Description Text - DETX (80): 

DataFile objects 328 represent tracked data files in the system and may 
include files imported from external media, files created as a side-effect of a 
system or client process, files extracted from a database, and files created 
outside the system (such as a word processor document) that have been entered 
into the system by a user for tracking purposes. The DataFile object 328 
records sundry information of interest about the file. A given DataFile object 
328 is associated with one Project object 316. The lifetime of a DataFile 
object 328 is specified by the Project object 316 it is associated with. 



Detailed Description Text - DETX (81): 

DataTable objects 330 represent tracked database tables in the system. The 
database tier contains both "production" tables (i.e. tables whose formats are 
fixed for a given client), and "project" tables that are created as a 
side-effect of processing the client data. The DataTable object 330 records 
sundry information of interest about the table. A given DataTable object 330 
is associated with one Project object 316. The lifetime of a DataTable object 
330 is specified by the Project object 316 it is associated with. 



Detailed Description Text - DETX (82): 

NineTrackTape objects (not shown) represent single-reel, nine-track tapes, 
that are usually associated with mainframe computers. NineTrackTape objects 
differ from basic Tapes in that they have tape density information associated 
with them. A given NineTrackTape object can be associated with one ClientBase 
object 314 (but a given ClientBase object 314 may be associated with many 
NineTrackTape objects, or more generally, with many other PhysicalMedia objects 



11/17/2003, EAST Version: 1.4.1 



332). 



Detailed Description Text - DETX (83): 

A PhysicalMedia object 332 describes the common attributes of physical media 
used for transporting data (such as magnetic tapes). These common attributes 
include not only characteristics of the physical media itself (such as its 
volume label), but also sundry information such as where it is physically 
located, when it was received, general comments, etc. A particular ClientBase 
object 314 can be associated with many PhysicalMedia objects 332 (but each of 
those can only be associated with a single ClientBase object 314). All 
PhysicalMedia objects 332 are cataloged by the Librarian so they can be 
tracked. PhysicalMedia objects 332 almost always have a finite lifetime, after 
which they are disposed of in some manner that is determined at the time they 
are cataloged. The lifetime of a PhysicalMedia object 332 is determined by the 
Project object 316 it is associated with. 



Detailed Description Text - DETX (84): 

A Tape object (not shown) represents any kind of magnetic tape media such as 
CartridgeTapes and NineTrackTapes. A Tape object can be thought of as an 
abstraction that collects common attributes shared by all tape objects . A 
TapeDrive object 334 represents tape drives in which magnetic tapes can be read 
and written. A TapeRack object 336 represents the racks in which magnetic 
tapes are stored. A TapeSlot object 338 represents a slot in a tape rack. 



Detailed Description Text - DETX (85): 
Miscellaneous Persistent Objects : 



Detailed Description Text - DETX (86): 

An Event object 340 represents an event that happened on the system that 
needs to be stored persistently in the event log database table. Event objects 
340 describe what happened, when it happened, what operation or process was 
being performed at the time the event occurred, and some notion of severity 
(although severity is hard to convey because it is usually a function of who is 
observing the event). Because Event objects 340 are associated with processes, 
they are implicitly associated with a particular ClientBase object 314 unless 
the Context under which the process was operating did not include a ClientBase 
object 314 (which is the case for processes operating on behalf of the present 
invention itself). UserEventAssoc objects 374 contain the Event objects 340 
that each User object 360 is interested in. 



Detailed Description Text - DETX (87): 

A CodeLook object 312 provides a long description for a given "code" (i.e. a 
short single word description or mnemonic), and associates the code with a 
CodeMaster object 310. All codes used in the system are stored in a single 
CodeLook table in the database. The codes that are grouped together are 
associated with the same CodeMaster object 310. 
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Detailed Description Text - DETX (88): 

A CodeMaster object 31 0 describes the different codes that are used by the 
system. This description includes the name of the table column associated with 
the code, a long description for the code, the length of the code, and whether 
or not new codes can be added to the list of codes associated with this code 
master. The possible code values for a given CodeMaster object 310 are stored 
in the CodeLook table, and are associated with the CodeMaster object 310 
through its unique identifier. 



Detailed Description Text - DETX (89): 

DMAMail objects 342 represent customers who do not want to receive promotion 
pieces from a mail marketing campaign. DMAPhone objects 344 represent 
customers who do not want to be contacted by phone on behalf of a telemarketing 
campaign. 



Detailed Description Text - DETX (90): 

A NotifyRegistry object 346 associates a notification name with a user who 
wants to have an e-mail and/or pager message sent to them when the notification 
occurs. NotifyRegistry objects 346 may include the name of the notification to 
dispatch, the user to dispatch the message to, and the transport mechanism to 
use to send the message (i.e. e-mail or pager). 



Detailed Description Text - DETX (91): 

A MinionLog object 348 represents a log message written to the MinionLog 
table by a minion. The MinionLog table is a general purpose area where any 
minion can store persistent advisory messages. A MinionLog object 348 may 
include the name of the minion that posted the message, when the activity 
occurred, an "activity code," an arbitrary message, and the ClientBase object 
314 and/or Project object 316 that the minion was operating on when the message 
was saved 



Detailed Description Text - DETX (92): 

A State object 350 simply associates a standard abbreviation for a state 
that is a member of the USA with the full state name. A ZipCity object 352 is 
a utility object that associates zip codes, counties, and states together. 



Detailed Description Text - DETX (93): 
Security Persistent Objects : 



Detailed Description Text - DETX (94): 

An Action object 354 describes the operations that a user can perform with 
the system. These Action objects 354 can be grouped into ActionGroup objects 
356. A given Action object 354 can be a member of zero or more ActionGroup 
objects 356. A given UserlD is associated with a ClientBase object 314 and an 
Action object 354 through a Permission object 358. In other words, a 
particular user can only perform a certain Action object 354 on a ClientBase 
object 314 if there is a Permission object 358 for it. 
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Detailed Description Text - DETX (95): 

An ActionGroup object 356 groups one or more actions together. ActionGroup 
objects 356 are an administrative convenience for assigning a collection of 
Action objects 354 to a UserlD and ClientBase object 314 rather than having to 
assign them one at a time. 



Detailed Description Text - DETX (96): 

A Permission object 358 associates a User object 360 with a ClientBase 
object 314 and an Action object 354. There will be one of these objects for 
every Action object 354 that a particular User object 360 is allowed to perform 
on a given ClientBase object 314. 



Detailed Description Text - DETX (97): 
Session Management Persistent Objects : 



Detailed Description Text - DETX (98): 

A ClientBase object 314 contains database and system resource management 
information for the different clients. This information may include a client 
name, database connection and access information, database status, default 
billing information, directory locations for data files associated with the 
client base object, and default resource expiration information. ClientBase 
objects 314 may have zero or more Project objects 316 associated with them. A 
particular ClientBase object 314 and its associated Project object 316 are only 
accessible by User objects 360 that have permission to work with those Project 
objects 316. A ClientBase object 314 may have a finite lifetime (i.e. it may 
only remain active for a period of time, then be taken off the system), or may 
be essentially perpetual. 



Detailed Description Text - DETX (99): 

DataSpace objects 362 describe the data spaces on disk where the database 
servers store table and index data. DataSpace objects 362 may describe the 
name of the data space, whether the data space is a "project" table data space 
or a "production" table data space, a brief description of the data space, and 
the ClientBase object 314 associated with the DataSpace object 362. 



Detailed Description Text - DETX (100): 

A Project object 316 is a named collection of work associated with a 
ClientBase object 314. A Project object 316 may include a description of the 
project, a project code and status, archival information, and information about 
where to store flat files associated with the project. Project objects 316 can 
be associated with one ClientBase object 314, zero or more DataTable objects 
330, zero or more DataFile objects 328, zero or more PhysicalMedia objects 332, 
zero or more JobStream objects 322 and ProcessStream objects 326, zero or more 
Session objects 364, one MatterNum object 308 for disk usage billing, and one 
MatterNum object 308 for processing billing. 
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Detailed Description Text - DETX (101): 

All User objects 360 that have access to a particular ClientBase object 314 
are able to access all of its Project objects 316. Multiple Sessions (and 
therefore multiple User objects 360) may work on a Project object 316 
concurrently. 

Detailed Description Text - DETX (102): 

A Session object 364 is a combination of a particular Computer and Context 
that represents a connection from a particular workstation to a project on 
behalf of a User object 360. A Session object 364 is always associated with 
exactly one Project object 316 and therefore with exactly one ClientBase object 
314. Sessions are created when User objects 360 connect to the present 
invention from some workstation application, and are used in nearly all other 
system messaging to establish the context in which those messages should 
execute. A User object 360 on a particular workstation computer may establish 
exactly one Session from that workstation. However, a User object 360 may 
establish concurrent sessions from different workstations. 



Detailed Description Text - DETX (103): 

A SysDefault object 366 stores default values for the present invention. 
These default values consist of key-value pairs in the form of strings. A 
UserDefault object 368 stores user-dependent default values for the present 
invention. These default values consist of key-value pairs in the form of 
strings, and can vary from one user to the next. 



Detailed Description Text - DETX (104): 

A User object 360 represents a user of the present invention. A User object 
360 is allowed to work on selected ClientBase objects 314, and has access to 
all Project objects 316 associated with those ClientBase objects 314. A user 
may connect to (i.e. establish a Session with) the present invention from any 
workstation computer that is able to communicate with the system, and may have 
concurrent Sessions from multiple workstations, limited to a single Session on 
a particular workstation. 



Detailed Description Text - DETX (105): 

The Expression object 370 contains expression and function information used 
by applications. The ClientExprAssoc object 372 contains each valid expression 
for each ClientBase object 314. The eo_sequence_table 376 keeps track of the 
last original identifier assigned to each object . The SecurityGuard table 378 
contains the userid and encrypted password for each valid user of the system. 
Only the security guard 136 (FIG. 1) has access to this table. 



Detailed Description Text - DETX (106): 
Client Objects 



Detailed Description Text - DETX (107): 
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Referring now to FIG. 7A, a block diagram of the persistent objects 
comprising the client objects 124 (FIG. 1), in accordance with one possible 
relational embodiment of the present invention, is illustrated. The present 
invention is not limited to the specific client objects 124 described or to the 
relational embodiment illustrated in FIG. 7A. Those persons skilled in the art 
will recognize that the present invention is designed to allow client objects 
124 to be added, deleted or changed, and the relationships between the client 
objects 124 to be changed according to the intended application of the present 
invention. The relational nature of the client objects 124 allow the present 
invention to be modified without extensive recoding. 



Detailed Description Text - DETX (199): 

Now referring to FIG. 7B, another block diagram of the persistent objects 
comprising the client objects 124 (FIG. 1), in accordance with one possible 
relational embodiment of the present invention, is illustrated. The following 
tables are similar in that none of them are used to store client data. 
Instead, they are used to help direct the application software processes that 
need to validate and load incoming client data. 



Detailed Description Text - DETX (203): 

Eo_sequence_table 490 assigns the next sequential value to a given table's 
primary key column. In the present invention, every table has an "artificial" 
primary key called an " Object ID" (OID). The value stored in the primary key 
of each table is a system generated sequential number. The application uses 
eo_sequence_table 490 to determine the next primary key value that is to be 
assigned for each table in the client objects 124. 



Detailed Description Text - DETX (204): 

DDColumn 492 is one of three tables used together to group related column 
names. DDColumn 492 stores the name of each column used throughout the client 
objects 124. Along with the column name, it also stores a brief description 
and what "type" of data it contains (e.g. DATE, CHAR(8), INTEGER, etc. . . ). 



Detailed Description Text - DETX (21 1): 

Referring to FIG. 8, a block diagram of the EOFLite components 126 (FIG. 1), 
in accordance with a preferred embodiment of the present invention, is 
illustrated. The EOFLite components 126 are designed to provide a 
"lightweight" binding layer for moving data back and forth between the client 
database 114 and high-volume "batch" processes. The EOFLite components 126 
create instances of custom classes without having to live with the overhead 
inherent in the lower-level EOF frameworks, which are designed more for 
OLTP-type processing than for record-by-record batch processing. 



Detailed Description Text - DETX (212): 

The EOFLite components 126 are designed to work with the same enterprise 
object classes that are used with EOF, so that a single object model can be 
developed that works the same for both interactive and batch processing (i.e. 
the same business logic will be used by both). The major classes in EOFLite 
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are designed to model familiar database concepts, such as the database itself, 
connections to the database, cursors in a connection, and bindings between the 
data being manipulated by a cursor and some object that is to be populated with 
that data. These components supplement the basic EOF "primitive" classes, such 
as EOModel 602, EOQualifier 604, EOEntity 606, and EOAttribute 608, and when 
used together result in a much more efficient mechanism for performing batch 
processing. The EOFLite components 126 are as follows: 



Detailed Description Text - DETX (216): 

EOAttribute 608 represents the table column whose data the receiver is 
binding to its object . 



Detailed Description Text - DETX (217): 

DBDatabase 610 represents a single physical database. Each instance of this 
class can be associated with zero or more DBConnection 612 instances. 



Detailed Description Text - DETX (219): 

DBCursor 614 represents data cursors operating through a connection. These 
instances are configured for a single entity and an associated class of objects 
whose instances will be populated with the data retrieved by the cursor. 



Detailed Description Text - DETX (220): 

DBBinding 616 represents bindings between a single EOAttribute 608, which 
represents a single column in a table, and a single instance variable of an 
object . These "bindings" are used by instances of the DBCursor 614 to map data 
between the attributes of an EOEntity 606 and the instance variables of the 
cursor's prototype object . 



Detailed Description Text - DETX (221): 

NSObject 618 is the object to and from which data is being mapped by the 
receiver. 



Detailed Description Text - DETX (222): 

String is a lightweight implementation of NSString that provides more 
external access to the internal representation of the string, and minimizes the 
amount of memory allocation overhead that takes place during string 
manipulation. This class is primarily provided as an optimization for batch 
processes that cannot afford the performance overhead of the NSString class . 



Detailed Description Text - DETX (223): 

Number is a lightweight implementation of NSNumberthat minimizes the amount 
of memory allocation overhead that takes place during data manipulation. This 
class is primarily provided as an optimization for batch processes that cannot 
afford the performance overhead of the NSNumber class . 
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Detailed Description Text - DETX (224): 

CalendarDate is a lightweight implementation of NSCalendarDate that 
minimizes the amount of computation overhead involved to manipulate dates. 
This class is primarily provided as an optimization for batch processes that 
cannot afford the performance overhead of the NSCalendarDate class . 



Detailed Description Text - DETX (266): 

An agent description consists of an agent name with an associated agent 
profile (discussed in a previous section), list of object descriptions, and 
list of additional frameworks to load to support the objects the agent will 
manage. 



Detailed Description Text - DETX (267): 

The System Configuration File is used both by interface-layer minion proxies 
(to locate their corresponding remote objects), and by obiect -laver agents (to 
determine their profile). This means that the System Configuration File must 
be in at least one shared location that is accessible across all machines that 
participate in the system. 



Detailed Description Text - DETX (272): 

Client-specific executable files for context-dependent agents are located in 
a path that is obtained from the client object in the context of the session 
that is making use of the agent (specifics forthcoming). 
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Brief Summary Text - BSTX (9): 

A preferred embodiment of the invention includes a system to transition an 
entire business enterprise to a distributed infrastructure. The distributed 
infrastructure is preferably a multi-tiered client/server target architecture 
that adheres to open system standards. The multi-tiered architecture 
preferably includes at least four layers including a separate process control 
layer and functionality layer. The process control layer includes a state 
router to control work flow in accordance with the business procedures of the 
enterprise. The functionality layer includes modules for performing the work. 
The architecture also preferably includes a presentation layer for interfacing 
with a user, and a data retrieval layer for accessing data stored in a separate 
data storage layer. 



Drawing Description Text - DRTX (2): 

The foregoing and other objects, features and advantages of the invention, 
including various novel details of construction and combination of parts will 
be apparent from the following more particular drawings and description of 
preferred embodiments of a system to transition an enterprise to a distributed 
infrastructure in which the reference characters refer to the same parts 
throughout the different views. It will be understood that the particular 
apparatus and methods embodying the invention are shown byway of illustration 
only and not as a limitation of the invention, emphasis instead being placed 
upon illustrating the principles of the invention. The principles and features 
of this invention may be employed in various and numerous embodiments without 
departing from the scope of the invention. 



Drawing Description Text - DRTX (9): 

FIG. 7 is a schematic diagram illustrating the business process layer 120, 
functionality layer 130. and data access layer 1 40 of FIG. 1 . 
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Drawing Description Text - DRTX (32): 

FIG. 30 is a block diagram of the graphical business object editor 330 of 
FIG. 1. 



Detailed Description Text - DETX (3): 

A preferred multi-tiered architecture 10 of the present invention comprises 
at least four separate layers. As illustrated, the architecture 10 includes at 
least one presentation layer 110. one separate business process layer 120, one 
separate functionality layer 130. one separate data access layer 140. one 
separate data storage layer 150, and one separate control layer 160, all 
inter-connected through communication links 170. The data storage layer 150 
preferably includes a user interface repository 152, a business process 
repository 154, a business object repository 156, and a data record repository 
158 for storing data. 



Detailed Description Text - DETX (5): 

A preferred re-engineering system includes a graphical user interface editor 
310, a graphical business process editor 320, a graphical business object 
editor 330, a graphical data editor 340, a logic development environment 350, 
and facilitation tools 360. The logic development environment 350 is in 
communication with the functionality layer 1 30 of the multi-tier architecture 
10. The graphical user interface editor 310, the graphical business process 
editor 320, the graphical business object editor 330, and the graphical data 
record editor 340 are in communication with the user interface repository 152, 
the business process repository 154, the business object repository 156, and 
the data record repository 158, respectively. 



Detailed Description Text - DETX (8): 

FIG. 2 is a functional block diagram of the interrelationships of FIG. 1. 
Conceptually, the user interface translator 210 and the graphic user interface 
editor 310 affect the presentation layer 110 of the multi-tiered architecture 
10. The graphical business process editor 320 affects the business process 
layer 120. The procedural language conversion utility 220, the graphical 
business object editor 330, and a logic development environment 350 
conceptually affect the functionality layer 1 30. The procedural language 
conversion utility 220 also conceptually affects the data access layer 140. 
The data definition language translator 230 and the graphical data record 
editor 340 conceptually affect the data storage layer 150. 



Detailed Description Text - DETX (28): 

A preferred embodiment of the present invention uses a frame-type 
representation in an object -oriented organization in which the frames represent 
objects . More specifically, the frames representing general concepts are 
referred to as classes and those representing specific occurrences of a concept 
are referred to as instances. In this context, attributes are termed members, 
and member inheritance and procedural attachment take place as in a frame 
system. 
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Detailed Description Text - DETX (29): 

In object -oriented systems, however, objects communicate with one another by 
sending and receiving messages. When an object receives a message, it consults 
its pre-defined answers for messages to decide on what action to take. These 
answers can be stored directly with the object or inherited from a higher level 
object somewhere in the network hierarchy. Usually, the action involves 
triggering some rules, executing procedural code, or sending new messages to 
other objects in the system. 



Detailed Description Text - DETX (30): 

Similarly to the display platform user interface representation structures 
118, the application user interface representation structures 116 store 
descriptive information representative of the different objects that compose a 
user interface. Each object is described by a structure comprising a plurality 
of fields containing information representing an attribute of that object or a 
relationship between the object and another object The user interface engine 
117 maps each of the different objects that compose the user interface of a 
given application into the corresponding representations 118 in the user 
interface display platform 1 15 of choice for that application. 



Detailed Description Text - DETX (33): 

FIG. 5 is a schematic diagram of a sample mapping between application user 
interface representation structures 116 and display platform user interface 
representation structures 118. In the figure, the user interface display 
platform 115 is exemplified as Microsoft Windows 3.x and the display platform 
user interface representation structures 1 17 are thus the internal Windows 3.x 
management structures. However, other user interface display platforms 115 
using similar internal structures to manage windows are supported by the exact 
same user interface engine 117. Notably, the internet's world-wide web, based 
on the HTML or Java user interface languages, is another example of user 
interface display platform 115. Indeed, in a preferred embodiment of the 
present invention, the user interface engine 117 is written using Microsoft 
Visual C++ and based on the industry-standard Microsoft Foundations Classes 
(MFC) class library, which allows cross-platform development for Windows 3.x, 
Windows 95, Windows NT, MacOS, and UNIX-based user interface display platforms 
115, including internet web servers. 



Detailed Description Text - DETX (35): 

During initialization, the user interface engine 117 first initializes its 
initial state, setting up any structures necessary for operation. Depending on 
the implementation, the user interface engine 117 can then initialize 
communications with the business process layer 120, receiving a client 
identification number. Depending on the implementation, the user interface 
engine 117 can also display an initial application menu or screen, initial 
objects that are provided by the business process layer 120. 



Detailed Description Text - DETX (36): 
After completing the initialization, the user interface engine 117 continues 
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to the user input module 117-2. The user interface engine 1 17 waits for user 
input and processes it accordingly. In particular, the user input module 117-2 
handles interactions with GUI objects and performs application-dependent 
actions in response to user inputs. 



Detailed Description Text - DETX (40): 

Essentially, during idle message polling the user interface engine 117 
queries the state router for any initial messages. At the start of an 
interactive application, a first screen needs to be displayed to the user. 
This screen is usually a sign-on, or logon, screen which contains fields for 
the user identifier and user password, with possibly peripheral buttons to 
change the user password and access help screens. In addition, other graphics, 
such as an application logo or wallpaper, might be decorating the screen. 
After these initial messages have been processed, resulting in the display of 
the logon screen, application menu, and other object for the user to act upon, 
the user interface engine 1 1 7 waits to process user inputs. If the user takes 
no action and idle message polling is enabled, the user interface engine 117 
will periodically query the state router for any messages. If message polling 
is disabled, the user input loop will continue indefinitely. Using a window 
mapping structure, which is preferably a two-way associative array, it is 
possible for the user interface engine 1 17 to allow window control handlers of 
the user interface display platform 111 to manage general window operation and 
make callbacks to the user interface engine handlers when an action is 
required, for example, when a button is pressed. 



Detailed Description Text - DETX (41): 

In a preferred embodiment of the present invention, the user interface 
engine 117 can process any type of action from any type of screen object e.g. 
a button being pressed, a control gaining the input focus, or the Tab key being 
pressed. Typically, when an action is performed, one of two things may happen: 
the user interface engine 117 performs some internal function based on the 
action, or sends information to be processed back to the business process layer 
120. In a particular preferred embodiment of the invention, all actions are 
referred back to the business process layer 120 for processing, along with any 
updated field values. 



Detailed Description Text - DETX (42): 

FIG. 7 is a schematic diagram illustrating the business process layer 120, 
functionality layer 130. and data access layer 140 of FIG. 1 . In a preferred 
embodiment of the invention, these layers can be hosted on similar platforms. 
In a preferred embodiment of the present invention, these platforms include a 
host processor 132, in which the various engines are resident, internal or 
external storage 134, on which the logic or data access server runtime 
environment resides, and a terminal console 136 which serves as a human 
interface for host administration purposes. In addition, a communications 
controller 1 38 such as a LAN controller, modem or similar device serves as an 
interface to a communication link. The host computer system 132 can be 
considered conventional in design and may, for example, take the form of a E55 
workstation, manufactured by Hewlett Packard Corporation. As shown, the 
business process layer 120, functionality layer 130. and data access layer 140 
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further include a printer 135 which can be used to provide a permanent record 
of application log files, reports, source code, or process objects and flows 
according to the present invention. 



Detailed Description Text - DETX (47): 

The unpacking procedure converts the request string into an array of request 
application user interface representation structures 121. This array is then 
passed to a main state router 122-1 function, which accounts for the core 
processing of the state router 122. Routing logic 122-2 then directs the 
objects to servers in the functionality layer 130 or the database layer 140. 
Once the state router 122 completes its processing, the resulting array of 
return application user interface representation structures 121 is again packed 
into a return string, which is passed back to the user interface engine 117 
using an RPC mechanism 122-9. 



Detailed Description Text - DETX (48): 

Because new application user interface representation structures 121 can be 
added to facilitate the transport of new types of objects as required by a 
particular application, the packing and unpacking functions include a library 
having primitives which pack and unpack bytes (8-bit integers), words (16bit 
integers), double words (32-bit integers), and strings (both variable- and 
fixed-length). To create a new application user interface representation 
structure 121, a developer need only create packing and unpacking routines for 
that structure, assembling these functions from the primitive routines. 



Detailed Description Text - DETX (49): 

In the preferred embodiment of the present invention, the packing and 
unpacking library is written in such a way that the same source code compiles 
using structures (under ANSI C) or using object classes (under ANSI C++). 
Although the ANSI C language interface is very usable, the ANSI C++ language 
interface makes use of object -oriented features such as virtual functions to 
make packing and unpacking as transparent as possible. High-level packing and 
unpacking routines take arrays (or, in ANSI C++, containers) of application 
user interface representation structures 121 and create a single character 
string containing the packed information suitable for RPC transmission. This 
string contains type information as well as member data, so that any sequence 
of application user interface representation structures 121 can be sent and 
properly reconstructed at the receiving end. 



Detailed Description Text - DETX (65): 

FIG. 11 is a block diagram of the functionality layer 130 of FIG. 1. 
Conceptually, the functionality layer 130 manages the business objects 
manipulated by the business process layer 120. These business objects 
constitute the fundamental components of an application. In a traditional 
manual system, a business object is associated with one or more physical paper 
forms. These forms contain the fields that hold the information relevant to 
the business object . Forms differ not only in their physical appearance, but 
also in the rules that govern their use. For example, a highly confidential 
form is treated differently from a non-confidential form. Other business rules 
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may also govern the handling of forms. For example, some invoices might 
require more than one signature if their amount is bigger than a certain value. 
It is the form and the rules that govern its handling that define a business 
object in a traditional manual system. 



Detailed Description Text - DETX (66): 

The business objects represent the physical forms, the information in those 
forms, and the rules that govern these forms. As discussed previously in the 
context of a re-engineering or custom-developed application, the business 
process engine 124 of the business process layer 120 manages the flow of 
business objects, interprets their rules, and acts on these rules. 



Detailed Description Text - DETX (74): 

FIG. 12 is a block diagram of the data access layer 140 of FIG. 1 . The data 
access layer 140 comprises a number of data servers. As mentioned previously, 
the data servers are used to access and retrieve data from the data storage 
layer 150. Preferably, one data server exists for each of the four application 
object repositories. Consequently, there is user interface data server 141 to 
manipulate user interface objects 142. a business process data server 143 for 
business processes 144, a business object data server 145 for business objects 
146, and a database server 147 for application data records 148. The data 
servers constitute the sole interface between the data storage layer 140 and 
the functionality layer 130, and each data server is only in charge of 
exchanging with the functionality layer 130 information about the type of 
application object it services. 



Detailed Description Text - DETX (78): 

The data access layer 140 can now be viewed as a set of database access and 
retrieval functions. There is one function for each one of the data access 
construct of the source Data Base Management System (DBMS). Each such function 
must emulate the behavior of the corresponding source DBMS data accessor 
construct. In the preferred embodiment of the present invention, the target 
DBMS is typically based on a conventional relational model, and is called a 
Relational DBMS (RDBMS). The source DBMS can be built around a number of 
conventional data models. The most common such models are the flat file, 
hierarchical, network, CODASYL (Conference on Data Systems Languages), 
relational, and object- oriented data models. 



Detailed Description Text - DETX (84): 

FIG. 13 is a block diagram of the data storage layer 150 of FIG. 1 . The 
data storage layer 150 is a repository for data accessed by the data access 
layer 140. The user interface data repository 152 provides user interface 
objects 153 to the data access layer 140. The business process data repository 
154 provides business processes 155 to the data access layer 140. The business 
object data repository 1 56 provides business objects 1 57 to the data access 
layer 140. The application data records repository 158 provides data records 
1 59 to the data access layer 1 40. 
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Detailed Description Text - DETX (86): 

A preferred embodiment of the present invention uses the relational data 
model for the data storage layer. The relational data model can be viewed at 
three different levels: conceptual, logical, and physical. The conceptual 
level consists of entities, attributes, and relations. Entities are things 
that exist on their own, distinguishable from other objects . Entities 
(records, rows) are described in terms of their attributes (fields, columns). 
Relations are common fields between entities used to connect entities together. 
The Entity-Relationship data model (ER) is the predominant conceptual level 
description tool. It is used as a diagramming technique where rectangles 
represent entities, circles represent attributes, diamonds represent 
relationships. The logical level consists of records, fields, and relations. 



Detailed Description Text - DETX (98): 

Configuration management 167 provides libraries for a number of diverse 
purposes. For instance, application version management functions are provided. 
In addition, currency is handled through locking functions to insure data 
consistency. Data integrity is controllable at the functionality layer by the 
business objects rules or constraints. The underlying database management 
system usually provides data integrity controls implicitly available to 
applications, but the usage of such controls are not recommended because it 
would mean encoding business logic in the data layer 150 instead of confining 
it to the functionality layer 130, and would therefore be contrary to the 
fundamental principle of the preferred multi-tiered architecture. 



Detailed Description Text - DETX (137): 

FIGS. 23A-23B are C and C++ target code fragements 227\ 227", respectively, 
for the source code fragment of FIG. 18. As illustrated, the intermediate 
language illustrated in the output file 225' of FIG. 21 is transformed into a 
select target language source code 227. The target language can be any 
procedural programming language (such as C) or any object -oriented programming 
language (such as C++). As described, a different second phase transformer 
program 226 is used to generate source code in each target language. 



Detailed Description Text - DETX (155): 

As mentioned previously with regard to FIG. 1 , the custom and re-engineering 
system 30 focuses on providing an enterprise a facility for maintaining and 
enhancing distributed infrastructure. Even though this facility is an integral 
part of the overall system of the present invention, it is really an add-on 
facility that becomes paramount once the transition is complete. Consequently, 
only an overview of the custom and re-engineering system 30 will be provided 
here. At a high-level therefore, the custom and re-engineering system 30 
includes a graphical user interface editor 310, a graphical business process 
editor 320, a graphical business object editor 330, a graphical data record 
editor 340, a logic development environment 350, and facilitation tools 360. 



Detailed Description Text - DETX (157): 

FIG. 28 is a block diagram of the graphical user interface editor 310 of 
FIG. 1. The graphical user interface editor 310 is a typical user interface 
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made to create menus and paint screens. As such, the graphical user interface 
editor 310 includes a screen editor 31 1 to position graphical representations 
of business objects on a screen or form. Screens can thus include text fields, 
labels, buttons, selection boxes, pull down lists, and similar graphical 
objects that compose a user interface. These graphical representations of 
business objects can be grouped so that a screen can be composed of 
sub-screens. This is useful to represent screen overlays, which are screens 
that have a fixed area as well as a variable area that changes depending on 
user actions. Sub-screens are also useful for grouping together business 
objects that need to be displayed across a number of application screens. The 
screen editor 31 1 creates internal user interface representations 312 which are 
processed by a user interface code generator 313 into data stored in the user 
interface repository 152. 



Detailed Description Text - DETX (162): 

FIG. 30 is a block diagram of the graphical business object editor 330 of 
FIG. 1 . The graphical business object editor 330 is a tool that enables the 
graphical editing of business objects and their relationships. A business 
object editor 331 generates internal business object representations which are 
converted by a business object code generator into data stored in the business 
object repository 1 56. 



Detailed Description Text - DETX (163): 

In a preferred embodiment of the present invention, the graphical business 
object editor 330 can be viewed as a Entity-Relationship (ER) diagramming tool. 
The ER data model is the predominant conceptual level description tool and is 
used as a diagramming technique where rectangles represent entities, circles 
represent attributes, diamonds represent relationships. This graphical ER 
diagram can be used to generated automatically the application database schema, 
and a number of the basic data accessor queries. 



Detailed Description Text - DETX (164): 

In addition, default constraints can be automatically associated to business 
objects based on the business object type. This can lead to automatic 
generation of maintenance screens for lookup business objects that can take a 
known range of values. The graphical business object editor can also be used 
to create templates that can be reused throughout an application. For 
instance, every screen may have a number of fixed function keys or buttons such 
as display, insert, delete, update, clear, refresh, backup, or quit, as well as 
a number of variable function keys whose semantics change from screen to 
screen. These function keys can be treated as a group and provided 
automatically as part of the template for every screen in an application. 



Claims Text - CLTX (9): 

6. The system of claim 1 wherein the target application is an 
object -oriented application. 



Claims Text -CLTX (21): 
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15. The method of claim 10 wherein the target application is an 
object -oriented application. 



Claims Text - CLTX (50): 

32. The system of claim 27 wherein the target application is an 
object- oriented application. 



Claims Text- CLTX (61): 

41 . The method of claim 36 wherein the target application is an 
object -oriented application. 



Other Reference Publication - OREF (3): 

Berg, K.S., "Business Objects Done Right," Software Reviews, 20(4):175-176, 
(Apr. 1995). 
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SYSTEM TO TRANSITION AN ENTERPRISE 
TO A DISTRIBUTED INFRASTRUCTURE 

RELATED APPLICATIONS 

This application claims priority to U.S. Provisional Appli- 
cation No. 60/016,330 filed on May 3, 1996, the teachings 
of which are incorporated herein by reference in their 
entirety. 

BACKGROUND 

Corporations characteristically use applications executing 
on computer systems to automate their business functions. 
The applications typically contain parts that deal with the 
user interface, parts that deal with business processes, parts 
that deal with programming logic, and parts that deal with 
data. The applications are typically built to operate on a 
single computer platform. In this context, a computer plat- 
form includes the programs, or software, to perform the 
various tasks required of a computer, as well as the machine, 
or hardware, that hosts these programs. 

Given the large amount of business functions that need to 
be automated within a corporation, applications are often 
centralized on one single platform. From a hardware point of 
view, such platforms include large and powerful computers 
such as mini-computers or mainframes. On the software 
side, such platforms often take the form of all-encompassing 
environments that meet all of the application development 
needs, such as Information Management System/Virtual 
Storage (IMS/VS) from International Business Machines 
Corporation (IBM). In the IMS/VS model, the various 
conceptual layers constituting an application are bundled 
together in one single piece or a small number of inter- 
dependent pieces. This single-tier model is well understood, 
reliable, and secure. It facilitates control and limits over- 
head. 

The proprietary nature of the host platform, however, 
leads to severe economic disadvantages. Initial platform 
costs are sizable, and subsequent growth is limited by the 
capacity of the hardware and software components of the 
platform that hosts the application. Furthermore, application 
maintenance and enhancement is a complex and cumber- 
some process. Application users are removed from applica- 
tion developers, increasing the gap between requirements 
and implementation. Changes to one part of the application 
also require compatible changes to the other parts of the 
application. Finally, data access and communication stan- 
dards are limited to those supported by the host platform. 

The advent of desktop computing in the form of the 
personal computer provides an initial solution to the above 
problems by enabling corporations to depart from the cen- 
tralized platform model. To maximize the usage of their 
computer resources, applications can be distributed among 
different platforms. This distributed system approach can 
take many forms, the most widespread of which is known as 
the two-tiered client/server architecture. This two-tiered 
model divides the application between two platforms: a 
client and a server. At a high level, clients and servers are 
software concepts. A client makes requests from servers, 
while servers provide adequate services to fulfill client 
requests. Client hosts are typically personal computers, 
while server hosts are typically mini-computers or main- 
frame computers. 

In the client/server model, the presentation part of the 
application is usually located on the client platform and the 
data part of the application is found on the server platform, 
with the business process and functionality parts of the 
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application merged into either of the other two layers. This 
model is more economical than the single-tier model, with 
less or no hardware lock-in. The division into two tiers is 
also more flexible to user interface changes. On the other 
5 hand, the proprietary nature of the platform is still present at 
the level of the software. 

SUMMARY OF THE INVENTION 

Even in the two-tiered client/server model, the mixing of 

10 functionality with either presentation or data still leads to 
complicated code changes. Also, data access and commu- 
nication standards are still limited. Furthermore, enterprises 
have no facilities to transition their existing infrastructure to 
a distributed computing model. 

15 A preferred embodiment of the invention includes a 
system to transition an entire business enterprise to a dis- 
tributed infrastructure. The distributed infrastructure is pref- 
erably a multi -tiered client/server target architecture that 
adheres to open system standards. The multi-tiered archi- 
tecture preferably includes at least four layers including a 
separate process control layer and functionality layer. The 
process control layer includes a state router to control work 
flow in accordance with the business procedures of the 
enterprise. The functionality layer includes modules for 

25 performing the work. The architecture also preferably 
includes a presentation layer for interfacing with a user, and 
a data retrieval layer for accessing data stored in a separate 
data storage layer. 

30 A transition of an entire business enterprise to a distrib- 
uted infrastructure based on the new architecture is per- 
formed using a process for organizing and managing the 
transition. Notably, this requires that each legacy (source) 
application be identified and prioritized. For each source 

35 application, there are a range of available transition choices, 
including the option of translating the source application to 
the new target architecture without changing any of the 
existing functionality arid the option of re-engineering the 
source application by changing the existing functionality. 

^ The source application may also be replaceable by a com- 
mercial product or a custom application written in-house. 
The source applications are then transitioned in order of 
priority to the new architecture. 

Specifically, a preferred system in accordance with the 

45 present invention includes the automated capability to trans- 
late existing source applications into new target applications 
on a multi-tiered client/server architecture. The translation 
of source applications to target applications includes the 
conversion of user interfaces, procedural languages, and 

50 data definitions. These conversions use a two-phase process 
where source program components written in the source 
languages are first translated to components in a common 
intermediate language. The intermediate language compo- 
nents are then translated to target program components in the 

5 5 target languages. By using a common intermediate 
language, only one translation module is required for each 
source and target language. 

A preferred system in accordance with the present inven- 
tion further includes a facility to create a new application 

60 based on the multi-tiered client/server architecture and to 
modify an existing application that already uses this multi- 
tiered client/server architecture. 

BRIEF DESCRIPTION OF THE DRAWINGS 

65 The foregoing and other objects, features and advantages 
of the invention, including various novel details of construc- 
tion and combination of parts will be apparent from the 
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following more particular drawings and description of pre- 
ferred embodiments of a system to transition an enterprise to 
a distributed infrastructure in which the reference characters 
refer to the same parts throughout the different views. It will 
be understood that the particular apparatus and methods 
embodying the invention are shown by way of illustration 
only and not as a limitation of the invention, emphasis 
instead being placed upon illustrating the principles of the 
invention. The principles and features of this invention may 
be employed in various and numerous embodiments without 
departing from the scope of the invention. 

FIG. 1 is a high level block diagram of a system embody- 
ing the invention. 

FIG. 2 is a functional block diagram of the interrelation- 
ships of FIG. 1. 

FIG. 3 is a schematic block diagram of a process for 
managing the transition of an entire enterprise to a distrib- 
uted infrastructure. 

FIG. 4 is a schematic diagram of the presentation layer 
110 of FIG. 1. 

FIG. 5 is a schematic diagram of a sample mapping 
between application user interface representation structures 
116 and display platform user interface representation struc- 
tures 118. 

FIG. 6 is a block diagram of the operational modules of 
the user interface engine 117 of FIG. 4. 

FIG. 7 is a schematic diagram illustrating the business 
process layer 120, functionality layer 130, and data access 
layer 140 of FIG. 1. 

FIG. 8 is a block diagram of the business process layer 
120 of FIG. 1. 

FIG. 9 is a flow diagram of the communication mecha- 
nism between the user interface engine 117 and the state 
router 122. 

FIG. 10 is a flow diagram of the operations of a particular 
preferred state router 122 of FIG. 8. 

FIG. 11 is a block diagram of the functionality layer 130 
of FIG. 1. 

FIG. 12 is a block diagram of the data access layer 140 of 
FIG. 1. 

FIG. 13 is a block diagram of the data storage layer 150 
of FIG. 1. 

FIG. 14 is a schematic diagram of a hardware platform for 
the data storage layer 150 of FIG. 19. 
FIG. 15 is a block diagram of the control layer 160 of FIG. 

1. 

FIG. 16 is a block diagram of the user interface conver- 
sion utility 210 of FIG. 1. 

FIG. 17 is a flow diagram of the procedural language 
conversion utility 220 of FIG. 1. 

FIG. 18 is an exemplary source code fragment. 

FIG. 19 is a block diagram of the first phase transformer 
program 224 of FIG. 17. 

FIG. 20 illustrates in FIGS. 20A-20B a parse tree for the 
source code fragment of FIG. 18. 

FIG. 21 is an intermediate language file for the source 
code fragment of FIG. 18. 

FIG. 22 is a block diagram of the second phase trans- 
former program 22 of FIG. 17. 

FIGS. 23A-23B are C and C++ target code fragments 
there being source code fragment of FIG. 18. 

FIG. 24 is a block diagram of the data definition language 
conversion utility 230 of FIG. 1. 
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FIG. 25 is a block diagram illustrating a schema conver- 
sion. 

FIG. 26 is a block diagram of a converter 235a, 2356 of 
FIG. 25. 

FIG. 27 is a block diagram of the data converter 236 of 
FIG. 24. 

FIG. 28 is a block diagram of the graphical user interface 
editor 310 of FIG. 1. 
, FIG. 29 is a block diagram of the graphical business 
process editor 320 of FIG. 1. 

FIG. 30 is a block diagram of the graphical business 
object editor 330 of FIG. 1. 

FIG. 31 is a block diagram of the graphical data record 
is editor 340 of FIG. 1. 

FIG. 32 is a block diagram of the logic development 
environment 350 of FIG. 1. 

FIG. 33 is a schematic block diagram of the facilitation 
tools 360 of FIG. 1. 

20 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

FIG. 1 is a high level block diagram of a system embody- 
ing the invention. As shown, the system 1 includes a 

25 multi-tiered architecture 10, a re-architecting system 20 for 
converting source applications of an enterprise to target 
applications on the multi-tiered architecture 10, and a 
re-engineering subsystem 30 for custom application devel- 

3Q opment or re-engineering. 

A preferred multi-tiered architecture 10 of the present 
invention comprises at least four separate layers. As 
illustrated, the architecture 10 includes at least one presen- 
tation layer 110, one separate business process layer 120, 

3S one separate functionality layer 130, one separate data 
access layer 140, one separate data storage layer 150, and 
one separate control layer 160, all inter-connected through 
communication links 170. The data storage layer 150 pref- 
erably includes a user interface repository 152, a business 

^ process repository 154, a business object repository 156, and 
a data record repository 158 for storing data. 

A preferred re-architecting system 20 includes a user 
interface conversion utility 210, a procedural language con- 
version utility 220, and a data definition language conver- 

45 sion utility 230. The procedural language conversion utility 
220 is in communication with the functionality layer 130 
and the data access layer 140 of the multi-tier architecture 
10. The user interface conversion utility 210 is in commu- 
nication with the user interface repository 152 and the data 

50 definition language conversion utility 230 is in communi- 
cation with the data record repository 158. 

A preferred re-engineering system includes a graphical 
user interface editor 310, a graphical business process editor 
320, a graphical business object editor 330, a graphical data 

55 editor 340, a logic development environment 350, and 
facilitation tools 360. The logic development environment 
350 is in communication with the functionality layer 130 of 
the multi-tier architecture 10. The graphical user interface 
editor 310, the graphical business process editor 320, the 

60 graphical business object editor 330, and the graphical data 
record editor 340 are in communication with the user 
interface repository 152, the business process repository 
154, the business object repository 156, and the data record 
repository 158, respectively. 

65 Even though the re-engineering system 30 is an integral 
part of the overall system of the present invention, it is not 
part of the actual transition of an enterprise to a distributed 
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infrastructure. Instead, the re-engineering system 30 enables 
the enterprise to maintain and enhance its distributed infra- 
structure once the transition itself is complete. 

In its simplest form, a host for all the layers can be a single 
platform. At the other end of the spectrum, each layer can be 
hosted on a different platform. In the spirit of distributed 
systems, a preferred embodiment of the present invention 
hosts each layer on a separate platform, both in terms of 
hardware and software. In a preferred embodiment of the 
present invention, the architecture 10 supports both custom- 
developed applications as well as application converted 
from a legacy system. The IMS/VS legacy environment is 
used herein to illustrate, but not limit, architectural concepts 
that pertain to a converted legacy application. 

FIG. 2 is a functional block diagram of the interrelation- 
ships of FIG. 1. Conceptually, the user interface translator 
210 and the graphic user interface editor 310 affect the 
presentation layer 110 of the multi-tiered architecture 10. 
The graphical business process editor 320 affects the busi- 
ness process layer 120. The procedural language conversion 
utility 220, the graphical business object editor 330, and a 
logic development environment 350 conceptually affect the 
functionality layer 130. The procedural language conversion 
utility 220 also conceptually affects the data access layer 
140. The data definition language translator 230 and the 
graphical data record editor 340 conceptually affect the data 
storage layer 150. 

FIG. 3 is a schematic block diagram of a preferred process 
for managing the transition of an entire enterprise to a 
distributed infrastructure. Preferably, the transition manage- 
ment process 40 includes a series of high level serial stages, 
including an implementation strategy stage 42, an imple- 
mentation planning stage 44, a system implementation stage 
46, and an operation stage 48. As the transition management 
process 40 proceeds from the implementation strategy stage 
42 through to the operation stage 48, the amount of opera- 
tions support required by the legacy system decreases and 
the amount of operations support for the open system 
increases, as illustrated. ^ 

The implementation strategy stage 42 is a sequence of 
manual steps embodied in a Business Case and Implemen- 
tation Strategy (BCIS) process 420. The BCIS process 420 
determines the business and technology drivers of the 
enterprise, builds a business case analysis of the economic 
feasibility of the transition, and creates an implementation 
strategy that provides the basic outline of the organization of 
the transition. This can involve studies of the existing and 
envisioned organization, infrastructure, and technology, as 
well as an evaluation of the impact of the transition in these 
areas. A study of the organization analyzes methods for 
developing the skills necessary for the transition and to 
manage potential resistance to change. A study of the 
infrastructure analyzes the hardware, software, and network 
required to support the transition. A technology study ana- 
lyzes the tools, architectures, and other technologies neces- 
sary for the transition. Although the implementation strategy 
stage 42 is described as a manual process, an expert system 
can be employed to perform some or all of the processing. 

More specifically, the focus is first to define the current 
state of the enterprise, which provides the start point. This 
start point is defined through an assessment of the perfor- 
mance of the existing information technology in supporting 
current business goals, an assessment of the readiness of the 
organization to build and support a new environment, and an 
assessment of the limitations inherent to the existing infra- 
structure. 
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The next focus is to identify the mission of the enterprise. 
The mission will give a good idea of the on-going direction 
of the enterprise, with which all undertakings must be 
aligned. Once the mission is identified, a conceptual vision 
5 for the future of the enterprise is defined, consistently with 
the mission. 

Unlike the mission, the conceptual vision is not 
continuous, but must be attained within a predetermined 
time frame. This conceptual vision provides the destination 

10 point. Given its conceptual nature, the corporate vision must 
now be broken down into specific goals or objectives, that 
are numbered for reference. Outputs are then associated with 
each objective, as measurable outcomes that will clearly 
indicate the achievement of the associated objective. To 

15 secure this association, outputs are numbered consistently 
with their corresponding objectives. 

Now that a start point, a direction, and a destination point 
have been defined, the intermediate steps that lead to each 
outcome must be delineated. These constitute the factors that 

20 are critical to successful achievement of these outputs, and 
are consequently referred to as the Critical Success Factors 
(CSF). Each output is given a set of CSFs associated with it, 
with appropriate numbering for reference. At this point, a 
strategy is put into place for achieving all of the CSFs for 

25 each of the outputs. Each strategy is numbered consistently 
with the output at which it is meant to arrive. Finally, a set 
of specific short term action items is associated with each 
strategy, as a means to move from the current situation 
towards the first CSF for each output. As before, action items 

30 are numbered consistently with the CSFs they are meant to 
lead towards. The implementation strategy stage 42 provides 
a start point for the implementation planning stage 44. The 
implementation planning stage 44 includes an Applications 
and Process Portfolio Analysis (APPA) process 442, fol- 

35 lowed by a series of Applications Staging and Planning 
(ASAP) 444 sessions. The APPA process and the ASAP 
sessions can be performed manually or with the aid of expert 
systems. 

The intent of the APPA process 442 is to gather and 

40 document an inventory of all the current and envisioned 
applications and business processes of an enterprise. The 
APPA process 442 separates the strategic from the tactical, 
and for each one, determines the transition that needs to take 
place to move from the existing to the envisioned situation. 

45 The range of transition possibilities include: do nothing, 
re -architect, re-engineer, re- architect and then re-engineer, 
replace by an off-the-shelf commercial solution, replace by 
a custom solution built in-house, and integrate. The do 
nothing option retains the existing application or process as 

50 is. The re-architect option translates the existing application 
to the new architecture without changing any of the existing 
functionality. The re-engineer option changes the existing 
functionality while remaining on the same architecture. The 
option of combining re-architecting and re-engineering first 

ss translates the existing application into the new architecture, 
and then modifies the application functionality in the context 
of the new architecture. The option of replacing by an 
off-the-shelf commercial solution replaces the existing 
application with a corresponding application package which 

60 is used, with or without customization, to perform the 
function of the replaced application. This solution is not an 
alternative for strategic applications and processes due to the 
inherent strategic nature of such solutions and to the loss of 
competitive advantage of the enterprise should these solu- 

65 tion be built using tools and methods commercially available 
and thus easily reproducible. The option of replacing by a 
custom solution built in-house replaces the existing appli- 
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cation with a new application built from scratch, using the 
new architecture. The integration option combines the vari- 
ous applications (whether already present, re-architected, 
re-engineered, purchased, or custom developed) into the 
new architecture to obtain a coherent infrastructure based on 
the new architecture. 

Once this inventory is completed, applications and pro- 
cesses are prioritized, and the planning of the transition can 
be initiated, starting with the applications and processes with 
the highest priority. This transition planning corresponds to 
the ASAP process 444, which focuses on a single application 
or process. The ASAP process 444 focuses on the details of 
the existing and envisioned application or process, evaluates 
the scope of the transition effort, and prepares a detailed 
implementation plan to conduct the transition, including 
tasks, schedule, and resources. An ASAP process 444 is thus 
carried out for each application and process identified during 
the APPA process 442, in order of decreasing priority. 

Once the implementation planning stage 44 is completed 
as described above, the actual implementation stage 46 can 
be initiated. Depending on the transition alternative selected 
for a particular application or process, a different implemen- 
tation process may be applied. At the implementation stage 
46, multiple applications and processes can go through the 
transition in parallel. 

A Strategic Application Advancement (SAA) process 461 
is an automated implementation process that focuses on 
re-architecting. Re-architecting preserves an application's 
core functionality intact, transformed into a multi-tiered 
client/server architecture. Re-architecting is often followed 
by re-engineering to add or change existing functionality to 
accommodate new business processes. Re-architecting 
involves identifying the business goals, objectives, and 
processes encompassed by the system, determining the 
existing source and desired target architectures, defining 
information systems standards, determining infrastructure 
requirements, performing the actual conversion, providing 
any re-engineering required, including design documenta- 
tion for re-engineering requirements and technical docu- 
mentation for re-architected application maintenance, and 
empowerment of staff for application maintenance and 
enhancements. 

A Strategic Applications System Development (SASD) 
process 463 is a manual implementation process that focuses 
on re-engineering or custom development. The SASD pro- 
cess 463 encompasses the design and development of 
re-engineered or custom-built multi-tiered client/server 
applications conforming to open system industry standards. 
Re-engineering refers to modifications to an existing system, 
usually the product of a prior re-architecting effort. 
Re-engineering must take into account the maintainability 
and performance issues that arise when attempting substan- 
tial changes to an application designed for a legacy system 
and converted to a multi-tiered client/server architecture. 
Custom development refers to the creation of a multi-tiered 
client/server application from user requirements. 
Consequently, custom development follows familiar appli- 
cation life-cycle steps. 

A Tactical Applications Planning and Implementation 
(TAPI) process 467 is a manual implementation process that 
focuses on the usage of commercial off-the-shelf packages. 
This involves selection and customization of commercial 
packages to achieve reusable applications in very short time 
frames. The TAPI process 467 is targeted to tactical as 
opposed to strategic applications, because such applications 
are not critical to the competitive posture of the business and 
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therefore can make use of available packaged technology 
without endangering the competitiveness of an enterprise. 

An Open Systems Integration (OSI) process 469 is a 
manual implementation process that focuses on integrating 

5 applications that are purchased, newly custom developed, 
re-architected, or re-engineered to share data and screens. 
This process includes the definition of business goals and 
objectives, the definition of applicable business processes, 
the study of application interactions and data relationships, 

10 and the planning of hardware and software infrastructures. 
The OSI process 469 also includes the implementation of the 
integration, including detailed implementation plan and 
schedule and detailed requirements and design 
documentation, user acceptance testing, comprehensive 

1S technical documentation, and empowerment of support staff 
for the maintenance phase. One powerful example of inte- 
gration at the user interface layer using the OSI process 469 
is the creation of a corporate intranet using internet Hyper- 
Text Manipulation Language (HTML) or a highly-level 

20 language generating HTML, such as Java from Sun Micro- 
systems to provide a user-friendly, platform independent, 
common user interface to corporate application. 

Implementation also includes a Skills Enhancement and 
Empowerment (SEE) process 462 and an Operations Pro- 

25 cess Advancement (OPA) process 468. The SEE process 462 
focuses on organizational issues during implementation, 
such as changing management and personnel training. The 
OPA process 468 focuses on operational support of the 
applications developed by the other implementation 

30 processes, including standardization of tools and processes, 
infrastructure setup, and system operation. 

Once the implementation stage 46 is completed, the 
operations stage 48 begins. The operations stage 48 includes 
a Customer Service and Support (CSS) process 480, which 

35 can include initial or continued application maintenance and 
user support, full-size production and operations, and pos- 
sibly outsourcing of all information system needs. As men- 
tioned previously, the facilitation tools of the re-engineering 
system are available for electronic planning, tracking, and 

40 documentation of all the stages of the transition management 
process 40. 

FIG. 4 is a schematic diagram of the presentation layer 
110 of FIG. 1. In its simplest form, the presentation layer 110 
can be implemented using a conventional personal com- 

45 puter. It can also take the form of an X-terminal, a work- 
station console, or a Macintosh style interface display. As 
shown, the presentation layer 110 includes a processor 111 
having the current screen representation, constructed 
according to the principles of the present invention. The 

so processor is preferably a user workstation which includes a 
display unit through which commands or user selections can 
be entered via a keyboard or mouse. The processor 111 also 
includes internal or external storage, such as a disk device, 
from which a user interface engine is loaded into the 

55 memory of the processor 111 as required. For a personal 
computer, X-terminal, or workstation having a large main 
memory storage, the entire application front-end can remain 
resident, thereby enhancing system performance. The stor- 
age unit is also used to store presentation layer log files. The 

60 presentation layer U0 can further include a printer 113, 
connected to the processor 111 through a communication 
link, such as a parallel or serial port. The printer 113 can be 
used to provide a permanent record of application log files, 
reports, source code, or screen listings according to the 

65 present invention. 

As shown in FIG. 4, the presentation layer 110 includes a 
user interface display platform 115, an application user 
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interface representation mechanism 116, and a user interface 
engine 117. In a preferred embodiment of the present 
invention, the user interface display platform 115 is a 
conventional Graphical User Interface (GUI) tool, commer- 
cially available. Consequently, the user interface display 
platform 115 has its own internal user interface representa- 
tion mechanism 118 to display the various components of a 
user interface, usually in a graphical way. 

Preferably, the underlying internal user interface of the 
user interface display platforms 115 is preferably derived 
from a frame-based system. A frame system is a network of 
frames and relations, corresponding to the nodes and links of 
a mathematical graph. Frame systems are organized in a 
hierarchy in which the high-level frames represent more 
general concepts and the lower frames represent more 
specific concepts. At the lowest levels, the frames represent 
instances of those concepts. The concept at each frame is 
defined by a collection of attributes or properties which can 
have values and, in this respect, the frames and attributes in 
a frame system are comparable to the records and fields in 
a database system. Each attribute can have a descriptor 
associated with it to define the constraints on the values the 
attribute accepts. Each attribute can also have procedures or 
programs called daemons attached to it which are executed 
when the value of the attribute is modified. In such a system, 
a frame can inherit the attributes or properties of higher level 
frames. 

A preferred embodiment of the present invention uses a 
frame-type representation in an object-oriented organization 
in which the frames represent objects. More specifically, the 
frames representing general concepts are referred to as 
classes and those representing specific occurrences of a 
concept are referred to as instances. In this context, 
attributes are termed members, and member inheritance and 
procedural attachment take place as in a frame system. 

In object-oriented systems, however, objects communi- 
cate with one another by sending and receiving messages. 
When an object receives a message, it consults its pre- 
defined answers for messages to decide on what action to 
take. These answers can be stored directly with the object or 
inherited from a higher level object somewhere in the 
network hierarchy. Usually, the action involves triggering 
some rules, executing procedural code, or sending new 
messages to other objects in the system. 

Similarly to the display platform user interface represen- 
tation structures 118, the application user interface repre- 
sentation structures 116 store descriptive information rep- 
resentative of the different objects that compose a user 
interface. Each object is described by a structure comprising 
a plurality of fields containing information representing an 
attribute of that object or a relationship between the object 
and another object. The user interface engine 117 maps each 
of the different objects that compose the user interface of a 
given application into the corresponding representations 118 
in the user interface display platform 115 of choice for that 
application. 

On the one hand, the user interface engine 117 requests 
application user interface representation structures 116 from 
the business process layer 120. Once the business process 
layer 120 satisfies the request, the user interface engine 117 
converts the application user interface representation struc- 
tures 116 just received into user interface representation 
structures 118 that are expected by the user interface display 
platform 115 for display to the end user on a display station 
111. 

On the other hand, when the end user performs an action 
through the display station 111, such as selecting an item or 
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modifying information, the user interface engine 117 trans- 
lates that user request from user interface display platform 
representation structures 118 into the corresponding appli- 
cation user interface representation structures 116, which are 

5 then handed to the business process layer 120 for execution 
of the end user request 

FIG. 5 is a schematic diagram of a sample mapping 
between application user interface representation structures 
116 and display platform user interface representation struc- 

10 tures 118. In the figure, the user interface display platform 

115 is exemplified as Microsoft Windows 3.x and the display 
platform user interface representation structures 117 are thus 
the internal Windows 3.x management structures. However, 
other user interface display platforms 115 using similar 

15 internal structures to manage windows are supported by the 
exact same user interface engine 117. Notably, the internet's 
world-wide web, based on the HTML or Java user interface 
languages, is another example of user interface display 
platform 115. Indeed, in a preferred embodiment of the 

20 present invention, the user interface engine 117 is written 
using Microsoft Visual C++ and based on the industry- 
standard Microsoft Foundations Classes (MFC) class 
Horary, which allows cross-platform development for Win- 
dows 3.x, Windows 95, Windows NT, MacOS, and UNIX- 

25 based user interface display platforms 115, including inter- 
net web servers. 

FIG. 6 is a block diagram of the operational modules of 
the user interface engine 117 of FIG. 4. Tne user interface 
engine 117 includes an initialization module 117-1, a user 

30 input module 117-2, and a state router communications 
module U7-3. 

During initialization, the user interface engine 117 first 
initializes its initial state, setting up any structures necessary 

3S for operation. Depending on the implementation, the user 
interface engine 117 can then initialize communications with 
the business process layer 120, receiving a client identifi- 
cation number. Depending on the implementation, the user 
interface engine 117 can also display an initial application 

^ menu or screen, initial objects that are provided by the 
business process layer 120. 

After completing the initialization, the user interface 
engine 117 continues to the user input module 117-2. The 
user interface engine 117 waits for user input and processes 

45 it accordingly. In particular, the user input module 117-2 
handles interactions with GUI objects and performs 
application-dependent actions in response to user inputs. 

If the user performs an action that depends on remote 
processing, however, processing continues to the state router 

50 communications module 117-3. In the state router commu- 
nications module 117-3, the user interface engine 117 cre- 
ates outgoing application user interface representation struc- 
tures 116 from the screen data and packs these structures for 
delivery to the business process layer 120. Typically, the 

55 outgoing application user interface representation structures 

116 contain values of screen fields which have changed 
since the previous call to the business process layer 120. The 
packed application user interface representation structures 
116 are then sent to the business process layer 120, which 

60 returns packed application user interface representation 
structure 116 describing the result of the transaction. The 
packed application user interface representation structures 
116 returned from the business process layer 120 are then 
unpacked and processed. Error messages can then be 

65 displayed, the screen can be updated with the results of the 
transaction, or a new screen can be shown. As long as the 
business process layer 120 does not indicate a fatal error, the 
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user interface engine 117 processing continues (resumes the communications controller 138 such as a LAN controller, 
wait for user input) at the user input module 117-2 until the modem or similar device serves as an interface to a corn- 
user exits the application. munication link. The host computer system 132 can be 
Most of the user interface engine 117 processing occurs in considered conventional in design and may, for example, 
the handling of screens: building a screen from a description, 5 „ . „ : . * . worK5 « uon > 

manufactured by 

processing application-updated values from the business Hew ett Corporation. As shown the business pro- 

orocess laver 120 and sendina user-undated values to the hyer 120 ' ftmctl ° naLt y ,aver 13 °. 811(1 data acccss laver 

C^^l^J-i^^^fc ~TL1 T 140 father include a printer 135 which can be used to 

business process layer 120. If a new screen is sent from the ^ a ent ^ of application log fileS( ^ 

business process layer 120, the current screen is discarded mmx ^ or ^ objects F a ^j flows £ the ' 

and replaced by the new screen. Communication with the 10 p rcseD t invention 

business process layer 120, and more specifically its main FIG. 8 is a block diagram of the business process layer 

state router component (described below), is always initiated m of mG L Thc main compoacnt 0 f the business process 

by the user interface engine 117 because a remote procedure layer 12 o is a state router 122. Conceptually, the state router 

call (RPQ mechanism which interfaces the user interface 122 receives requests from the user interface engine 117 

engine 117 with the business process layer 120 is preferably 15 (FIG. 4) and, based on the request, determines which actions 

unidirectional and synchronous. to take. The state router 122 then calls upon the functionality 

To simulate asynchronous communication using a unidi- layer 130 to perform the selected action, passing any 

rectional synchronous RPC model, the user interface engine required information. Upon completion of the action by the 

117 includes an ability to periodically poll the state router for functionality layer 130, the state router 122 accepts any 

messages during the user interface engine's 117 idle time, 20 resulting return information and forwards it to the user 

namely when there is no user input to be processed. This interface engine 117. 

functionality is known as idle message polling. ^ requests received from the user interface engine 117 

c 11 j * -Ji ir *l • * _c include application user interface representation structures 

EssenUaUy, d ™f * dle ™™p f>^Z the user interface m The ^ lication ^ interface 4 resent ation struaures 

engine 117 queries the state router for any initial messages. 1$ m include t idcntiners , transaction codes, screen 

At the start of an interactive application, a first screen needs information, and input/output buffers. A request identifier is 

to be displayed to the user. This screen is usually a sign-on, me name of a function that needs to be executed in response 

or logon, screen which contains fields for the user identifier to the request. There is one request identifier for any user 

and user password, with possibly peripheral buttons to interface event caused by the user. In this regard, request 

change the user password and access help screens. In 3Q functions arc similar to the conventional callbacks found in 

addition, other graphics, such as an application logo or GU i languages such as X-Windows developed at the Mas- 

wallpaper, might be decorating the screen. After these initial sachusetts Institute of Technology, in Cambridge, Mass. 

messages have been processed, resulting in the display of the Transaction codes are used to determine where to redirect 

logon screen, application menu, and other object for the user the request. In this view, the state router 122 is simply a 

to act upon, the user interface engine 117 waits to process 35 switch that differentiates between request identifiers and 

user inputs. If the user takes no action and idle message ^5 appropriate action in the form of a call to a function of 

polling is enabled, the user interface engine 117 will peri- the functionality layer 130. Screen information is used to 

odically query the state router for any messages. If message keep track of the current state of the application. Input 

polb'ng is disabled, the user input loop will continue indefi- buffers are used to carry information from the presentation 

nitely. Using a window mapping structure, which is prefer- ^ i aycr no to the business process layer 120 -and output 

ably a two-way associative array, it is possible for the user buffers are used to carry information from the business 

interface engine 117 to allow window control handlers of the process layer 120 to the presentation layer 110. 

user interface display pktform 111 to manage general win- FIG. 9 is a Bow diagram of the communication mecha- 

dow operation and make callbacks to the user interface nism bctwC c Q the user interface engine 117 and the state 

engine handlers when an action is required, for example, 45 routcr 122 . As depicted, the user interface engine 117 

when a button is pressed. includes a user interface routine 117-6 and initiates the 

In a preferred embodiment of the present invention, the communication by calling a pass message function 117-8. 

user interface engine 117 can process any type of action The pass message function 117-8 first compresses the appli- 

from any type of screen object, e.g. a button being pressed, cation user interface representation structures 116 to be 

a control gaining the input focus, or the Tab key being 50 transmitted into a single request string using a packing 

pressed. Typically, when an action is performed, one of two procedure. The request string compression performed by the 

things may happen: the user interface engine 117 performs packing procedure is necessary because the outgoing appli- 

some internal function based on the action, or sends infor- cation user interface representation structures 116 cannot be 

mation to be processed back to the business process layer transferred efficiently as such across the communication 

120. In a particular preferred embodiment of the invention, 55 link. 

all actions are referred back to the business process layer 120 The pass message routine 117-8 then calls a remote 

for processing, along with any updated field values. procedure call (RPQ routine 117-9 for actual transmission 

FIG. 7 is a schematic diagram illustrating the business of the request string over the network. The RPC routine 

process layer 120, functionality layer 130, and data access 117-9 takes two parameters: the request string to be passed 

layer 140 of FIG. 1. In a preferred embodiment of the 60 from the user interface engine 117 to the state router 122 and 

invention, these layers can be hosted on similar platforms. In the return string to be returned to the user interface engine 

a preferred embodiment of the present invention, these 117 from the state router 122. From the point of view of the 

platforms include a host processor 132, in which the various state router 122, requests arrive in the form of strings of 

engines are resident, internal or external storage 134, on characters that need to be decomposed into the logical 

which the logic or data access server runtime environment 65 components of the request. Consequently, the first step taken 

resides, and a terminal console 136 which serves as a human by the state router 122 is to decompress the request string 

interface for host administration purposes. In addition, a into its logical components using an unpacking procedure. 
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The unpacking procedure converts the request string into message. This message identifier is used to retrieve the full 
an array of request application user interface representation message format from a database repository 152. This pro- 
structures 121. This array is then passed to a main state cess will be discussed in further detail below, 
router 122-1 function which accounts for the core process- The m ffl fe laced ^ a ffl structure ^ 
mg of the .state router RouUng lo gl c 122-2 then tocts 5 ^ ^ information, a message format 
the objects to servers in the functionality layer 130 or the t . lVC a. iTj 
datable layer 140. Once the state router 122 completes its 122a -\ ^ J £°?* B ^.fnhfier of the related screen 
processing, the resulting array of return application user as , weU 35 * e ldsnb6 f T 0 ' *? . next message. The screen 
interface representation structures 121 is again packed into jnformanon associated with lbs screen identifier is then 
a return string, which is passed back to the user interface in loaded ^ the da ' abase repository 152. This screen infor- 
engine 117 using an RPC mechanism 122-9. matlon 15 P* 5 ^ back to ^ user »> lerface 117 

Because new application user interface representation ' e,u P apphcatjorj user interface ^representation 

structures 121 can be added to facilitate the transport of new ^ U1 A ™ e ?** mt6 . rfacc e f£ De 117 thcn P 1 ^ 

types of objects as required by a particular application, the "jf , and awfute usel , ,n P ut ^ D » us ?" en ' crs or 

packing and unpacking functions include a library having , s fh^daU on t raen ^ pi^ a l^iilBy. Ihe user 

. . . l i j i . /a , . : ' \ 15 interface engine 117 translates this user input mto a request 

pnmitives which pack and unpack bytes (8-bit integers), ^ p HU 

words (16bit integers), double words (32-bit integers), and 10 me Stale router 

strings (both variable- and fixed-length). To create a new Based oa me contents of the request, the state router 122 

application user interface representation structure 121, a saves its Eternal state into an old-state structure, and the 

developer need only create packing and unpacking routines 20 current state is then updated with any new field values from 

for that structure, assembling these functions from the me interface engine 117. State information is repre- 

primitive routines. sented by a field state structure 1226. Then, the state router 

In the preferred embodiment of the present invention, the 122 determines which functionality server to call, 
packing and unpacking library is written in such a way that A*, mentioned previously, the request identifier, which 
the same source code compiles using structures (under ANSI 2 s describes a function to be executed, is included with the 
C) or using object classes (under ANSI C++). Although the request from the user interface engine 117. The state router 
ANSI C language interface is very usable, the ANSI C++ 122 verifies the user's authorization to perform this function, 
language interface makes use of object-oriented features and if authentication is successful, proceeds with its pro- 
such as virtual functions to make packing and unpacking as cessing. If unsuccessful, an error condition is set, and the 
transparent as possible. High-level packing and unpacking 30 user is informed of an illegal access attempt. Assuming that 
routines take arrays (or, in ANSI C++, containers) of appli- authentication is successful, the determination of which 
cation user interface representation structures 121 and create functionality server to call is followed by a preparation of 
a single character string containing the packed information the message to be used for communication between the state 
suitable for RPC transmission. This string contains type routcr 122 a °d the selected functionality server, using a 
information as well as member data, so that any sequence of 3S prepare to send message function 122c to build one or more 
application user interface representation structures 121 can messages to be put on the top of the outgoing Message 
be sent and properly reconstructed at the receiving end. Format Service (MFS) message queue 122<1 

In a preferred embodiment of the present invention, the For an MFS-aware functionality server, the message is 
state router 122 can be used to access the functionality layer built as follows. Each field in the message, assuming field 
130 having custom -developed functionality servers as well '-'40 length n, is allocated n bytes in the message at a predefined 
as functionality servers converted from the IMS/VS model. onset. Additionally, a field may have two additional bytes 
The IMS/VS model is centered around the message concept, allocated to it for passing the field's attribute in the message, 
where the term "message" is used to refer to the model's A field's value is placed in the message if either of the 
communication structures with the functionality layer 130. following conditions holds: if the field's value has changed 
In a basic IMS/VS model, the state router 122 performs four 4s ( wh ich is determined by comparing the value of the field in 
main conceptual functions: log-on processing, IMS commu- the current state to the value of that field in the previous 
nication modeling, message conversion, and log-off process- state), or if the field's attributes specify that its value should 
ing. Log-on processing consists of checking the user autho- always be placed in the message regardless of whether it has 
rization and issuing a client identifier. IMS communication been modified (this attribute is known as "pre-modified"). If 
modeling is decomposed into transaction routing, con versa- 50 the sp acc m the message for a field value placed in the 
tion management, and message formatting service. Trans- message exceeds the length of the field value itself, the 
action routing uses Input-Output Program Control Block allocated space is padded with the pad character specified 
(IO-PCB) and Alternate Program Control Block (ALT-PCB) for tnat field. Finally, if a field's value has not been modified, 
IMS structures to route calls and messages between pro- aQ d the pre-modified attribute is not set for that field, its 
grams. Conversation management uses an IMS Scratch Pad 55 s P ace in the message is filled with *@' characters. When all 
Area (SPA) to store the processing context. Message for- fields m the message have been considered, the message is 
matting services uses Message Input Descriptor (MID) and complete. The message is then sent to the functionality 
Message Output Descriptor (MOD) IMS control blocks to server designated to handle the current transaction code, 
format messages and screens. Message conversion performs The SPA X22e is provided as a functionality server- 
message packing and unpacking. Log-off processing per- 60 independent area of memory used for inter-functionality 
forms clean-up functions with commit point processing. server communication. The SPA 122e is either newly- 

FIG. 10 is a flow diagram of the operations of a particular initialized, upon the first communication with the function- 
preferred state router 122 of FIG. 8. Initially, when a logon ality server, or returned from the previous call to the 
request is received from the user interface engine 117 functionality server. 

through the request user interface structure 121a and then 65 When the call completes, a pointer is returned to the 

authorized, the state router's 122 internal state is initialized incoming MFS message queue 122/, where the functionality 

with the current transaction code and the identifier of the first server placed one or more messages for transmission to the 
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state router 122. The returned information includes an 
auxiliary buffer, a MOD structure, a SPA, and field value 
information similar to that of the message passed from the 
state router 122 to the functionality server. The auxiliary 
buffer specifies the name of the MOD structure. The MOD 
structure contains either a message identifier to describe the 
next message for updates to the current screen or a trans- 
action name to initiate a switch to a new screen. 

Upon receipt of this information, the state router 122 first 
determines whether the MOD structure contains a transac- 
tion or a message. If a transaction is present, indicating a 
screen switch, the new screen information is loaded from the 
database repository 152, and its information is included in 
the return application user interface representation structures 
121b destined for the user interface engine 117. The state 
router 122 then recalls the functionality server that corre- 
sponds to the new transaction in what is called an "imme- 
diate switch". On the other hand, if the MOD structure 
contains a new message name, the state router 122 retrieves 
the new message format from the database repository 152 
and passes it to a prepare to receive message function 122g, 
along with the incoming MFS message queue 122/. This 
function updates the structures and processes the return 
message in a manner similar to the processing of the request 
message. Notably, new values and attributes are entered into 
the state router's 122 internal state. The attributes returned 
with each field specify whether the field is to maintain its old 
value, revert to its original attributes, or clear its value. The 
new values and attributes are then included in the return 
application user interface representation structures 121 array 
passed back to the RPC mechanism for return to the user 
interface engine 117. 

The above description of the state router 122 operations 
focused on the case of communication with functionality 
servers converted from the IMS/VS environment. In the case 
of custom functionality servers, the state router 122 still 
processes requests received from the user interface engine 
117 in response to user interface event caused by the user in 
manner similar to that described earlier. However, much of 
the ensuing IMS/VS message processing can be bypassed in 
favor of a more generic mechanism embodied in the usage 
of a business process engine 124. 

In this custom model, the state router 122 still redirects 
processing to appropriate functionality servers based on the 
transaction codes received from the user interface engine 
117. However, when the functionality server returns, it 
passes back an event to the business process engine 124 
component of the state router 122. The business process 
engine 124 is an event handler implemented as a conven- 
tional non-deterministic finite automaton (NFA). 

By way of background, an NFA is a mathematical model 
that consists of a set of states, a set of input symbols, a 
transition function that maps state-symbol pairs to sets of 
states, an initial state, and a set of final states. A special case 
of NFA is the deterministic finite automaton (DFA), which 
can have no unlabelled edges and at most one edge with the 
same label leaving a given state. Where time-space tradeoffs 
are an issue, an NFA is slower than a DFA but consumes 
much less space. In any event, an NFA and a DFA are both 
appropriate representations for real-life business processes. 
Furthermore, an NFA can automatically be converted into a 
DFA using fundamental principles of state machines and 
finite automaton theory. Consequently, which representation 
is used is of little consequence to a preferred embodiment of 
the business process engine 124. In addition, because busi- 
ness processes can be composed of a series of unrelated 
processes or can even be decomposed into sub-processes, 
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more than one NFA, possibly organized in a hierarchical 
fashion, can be used to represent the various business 
processes modeled by an application. 

In any case, the business process engine 124 preferably 

5 implements an NFA as follows. Upon receiving an event 
from the state router 122, the business process engine 124 
first checks the validity of the event. If the event is valid, the 
business process engine 124 then examines all transitions 
out of the current state, which could be the initial state if this 

10 is the first call to the business process engine 124. If the 
business process engine 124 does not find a transition that 
corresponds to the event received from the state router 122, 
it simply remains in its current state, releasing control back 
to the state router 122. On the other hand, should the 
business process engine 124 find a transition that includes 

15 the event received, the current state is saved and the next 
state is derived by starting at the current state and following 
the transition corresponding to the event received. The next 
state thus reached now becomes the current state. 

Because states include initialization routines, the business 

20 . 

process engine 124 executes any initialization routine asso- 
ciated with the next state immediately upon arrival at this 
next state. This initialization function can require another 
transition followed by another change of state, and therefore 

25 the business process engine 124 ends its processing by 
calling itself recursively, based on the event returned by the 
initialization function. 

Acomplication can occur when a transition leads to a state 
that is not part of the business process modeled by the 

30 current NFA. In this instance, the business process engine 
124 needs to switch to the NFA containing the next state. For 
this purpose, the business process engine 124 also maintains 
a current business process set. This enables the business 
process engine 124 to keep track of its position in the 

35 business process or NFA hierarchy. 

FIG. 11 is a block diagram of the functionality layer 130 
of FIG. 1. Conceptually, the functionality layer 130 manages 
the business objects manipulated by the business process 
layer 120. These business objects constitute the fundamental 

40 components of an application. In a- traditional manual 
system, a business object is associated with one or more 
physical paper forms. These forms contain the fields that 
hold the information relevant to the business object. Forms 
differ not only in their physical appearance, but also in the 

45 rules that govern their use. For example, a highly confiden- 
tial form is treated differently from a non-confidential form. 
Other business rules may also govern the handling of forms. 
For example, some invoices might require more than one 
signature if their amount is bigger than a certain value. It is 

50 the form and the rules that govern its handling that define a 
business object in a traditional manual system. 

The business objects represent the physical forms, the 
information in those forms, and the rules that govern these 
forms. As discussed previously in the context of a 

55 re-engineering or custom-developed application, the busi- 
ness process engine 124 of the business process layer 120 
manages the flow of business objects, interprets their rules, 
and acts on these rules. 

In a preferred embodiment of the present invention, the 

60 functionality layer 130 must also be able to handle IMS/VS 
COBOL functionality code. In IMS, functionality codes are 
structured into transactions composed of a main program 
called a driver and transaction programs for the various 
function keys the driver handles. Accordingly, a function- 

65 ality server 135 performs a number of functions. 

These functions comprise include file processing, server 
initialization, transaction call resolution, transaction entry 
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point processing, and server wrap-up. Include file processing interface data server 141 to manipulate user interface objects 
comprises initializing global variables, notably the Program 142, a business process data server 143 for business pro- 
Specification Block (PSB) structures for each transaction. cesses 144, a business object data server 145 for business 
By way of background, a PSB defines, for a given objects 146, and a database server 147 for application data 
transaction, the database which may be accessed, the data- 5 records 148. The data servers constitute the sole interface 
base segments that are available, and the type of access between the data storage layer 140 and the functionality 
(read, update, etc.) which may occur. A PSB is also a layer 130, and each data server is only in charge of exchang- 
collection of Program Communication Blocks (PCB). A ing with the functionality layer 130 information about the 
PCB is an IMS structure to control the access to data as will type of application object it services, 
be described in detail below. 10 According to client/server technology, a server is any 
Server initialization comprises unpacking the message program that runs a function invoked by a different program, 
received from the state router 122, to obtain the SPA and its A server is thus a software concept that provides a way to 
call parameters, and assigning local function pointers. An package together a set of related functions. Consequently, it 
additional level of indirection for each transaction program could be implemented as a conventional third generation 
main routine is necessary for ANSI C to mimic the COBOL 15 language sub-routine or library. 

"goto" capability to span across routines and exit at any i n me present invention, a number of the components 

point in the program. referred to as libraries can be implemented as servers and 

Transaction call resolution comprises determining the vice versa. The server implementation, however, is better 

driver to call based on the transaction identifier specified in suited to inter-platform communication, and is a preferred 

the RPC received from state router 122, associating the 20 embodiment for the communication links of the present 

appropriate PSB structure obtained from the include file invention. 

with the selected driver, and calling the driver with its By way of background, servers can be left to run con- 
arguments. Once in the driver code, control flows according tinuously in stand-alone mode and accept requests from 
to defined COBOL language principles. Two COBOL con- multiple clients. The set of functions, or services, provided 
structs merit further description in the context of ANSI C by a server constitutes the server interface. This interface is 
functionality code converted from COBOL, namely special specified in an Interface Definition Language (IDL) file. The 
routines called entry points and COBOL variables. concept of servers is well known, and details of server 

Transaction entry point processing comprises performing development and operations, including stub generation and 

calls to transaction entry points in the converted COBOL 3Q IDL file syntax and specification are commercially available, 

functionality code. Transaction entry points include routines The data access layer 140 can now be viewed as a set of 

to perform calls to various local (sub) routines or external database access and retrieval functions. There is one func- 

COBOL library routines, as well as routines to establish tion for each one of the data access construct of the source 

communication with the data access layer 140 (ENTRY Data Base Management System (DBMS). Each such func- 

statement) and perform calls to the database server/IO 35 tion must emulate the behavior of the corresponding source 

devices (CBLTDLI). A typical database access consists of an DBMS data accessor construct. In the preferred embodiment 

initial GET call to populate the I/O work area, followed by of the present invention, the target DBMS is typically based 

modifications to the I/O work area for subsequent insert on a conventional relational model, and is called a Relational 

(ISRT) or replace (REPL) calls. After each database access, DBMS (RDBMS). The source DBMS can be built around a 

the return status of the call is checked to take action based ^ number of conventional data models. The most common 

on the result of the database operation. sucn models are the flat file, hierarchical, network, CODA- 

In a preferred embodiment of the invention, COBOL SYL (Conference on Data Systems Languages), relational, 

variables are implemented as COBOL structures. A COBOL and object-oriented data models. 

structure contains a data field, which consists of a pointer to By way of background, the flat file model is a generalized 

an area in memory used to store the value of the variable. 45 fii e management system that adds report generation and file 

Another field stores the length of this data memory area. The management additions to third-generation programming lan- 

COBOL structures also contain a mask, which is a string guages such as COBOL. An example of such as model is the 

describing the COBOL format specification for the variable. Report Program Generator (RPG) from International Busi- 

For example, a mask of "PIC X(3)" refers to a string of 3 ness Machines, Incorporated. The hierarchical model is a 

characters. Sometimes COBOL variables exist in a hierarchy 50 hierarchical tree of nodes made of records and fields, with 

of other COBOL variables. Consequently, the COBOL tree search capabilities. An example of such a model is IMS 

structures also contain the number of sub-variables or sub Data Language 1 (DL/1). The network model is an extension 

COBOL structures in the current variable or COBOL struc- 0 f the hierarchical model, where nodes may have more than 

hire hierarchy. A COBOL structure variable can thus be 0 ne parent. The network model is also referred to as 

viewed as pointing to a buffer containing its data, all sub 5S CODAS YL, which is the initial embodiment of this model 

COBOL structure variables pointing to the proper offsets in using owner and member records linked by pointers, as 

that buffer. originated by Honeywell Information Systems, Incorpo- 

The last function performed by the functionality layer 130 rated. Examples of the network model are Integrated Data 

is server wrap-up. Server wrap-up includes preparing return Store (IDS) from IBM, and Integrated Database Manage- 

data, notably packing the SPAM for return to the state router 60 ment System (EDMS) from Cullinet, Incorporated. Given the 

122. fundamental differences between these models, the data 

FIG. 12 is a block diagram of the data access layer 140 of access library must be careful to map the semantics of the 

FIG. 1. The data access layer 140 comprises a number of source database to the appropriate constructs in the target 

data servers. As mentioned previously, the data servers are database. 

used to access and retrieve data from the data storage layer 65 In its simplest form, this mapping results in a simulation 

150. Preferably, one data server exists for each of the four of the source DBMS in a relational model, which is not 

application object repositories. Consequently, there is user always ideal for readability and maintainability. A preferred 
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embodiment of this invention extends this mapping to a true interface for host administration purposes. DBMS log files 
conversion of the source data model to the relational data are stored in storage unit. A printer 157 is usually present for 
model. The initial relational model thus obtained is further database diagnostics or large data outputs. In addition, a 
normalized to a specified degree controlled by parameter LAN controller, modem or similar device serves as a corn- 
using a bacchus-normal form utility, leading to a true 5 munication link 159. Ibe DBMS and the host computer 
relational model. In the context of the present invention, system 151 can be considered conventional in design and 
such libraries exist for all the common source data models may, for example, take the form of an Oracle relational 
mentioned. Because an overwhelming majority of existing DBMS, manufactured by Oracle Corporation, and a T500 
database systems fall into one of the source data models mini^computer, manufactured by Hewlett Packard Corpora- 
above, it is likely that most existing applications can be 10 tion respectively. 

handled by one of these libraries with minor or no changes. A preferred embodiment of the present invention uses the 

In a preferred embodiment of the present invention, the relational data model for the data storage layer. The rela- 
source DBMS is IMS DL/1. As discussed previously, IMS tional data model can be viewed at three different levels: 
functionality code is structured into transactions composed conceptual, logical, and physical. The conceptual level con- 
of a main program called a driver and subprograms for the 15 sists of entities, attributes, and relations. Entities are things 
various function keys the driver handles. For every such that exist on their own, distinguishable from other objects. 
IMS transaction in the functionality server, an entry function Entities (records, rows) are described in terms of their 
is called once to initialize the database server. This entry attributes (fields, columns). Relations are common fields 
function calls a database server function through an inter- between entities used to connect entities together. The 
mediary to initialize the PCB structure in the database 20 Entity-Relationship data model (ER) is the predominant 
server. Then, every time the functionality server needs to conceptual level description tool. It is used as a diagram- 
access the database server, it calls the function CBLTDLI( ), ming technique where rectangles represent entities, circles 
which in turn calls a database server function to call the represent attributes, diamonds represent relationships. The 
appropriate database function (e.g., GET, INSERT, logical level consists of records, fields, and relations. 
DELETE, and REPLACE primarily). Communication 25 ^ ^ me logical level description tool. In the 
between the functionality server and the database server is relational model, a database schema consists of the descry- 
thus reduced to two functions: init and CBLTDU (which, in ti on 0 f th e meu - fi cWs> me fields f ormats an d 
IMS, stands for CoBoLTo Data Language 1). domains. The relational algebra provides the theoretical 

The main function of a database server is to fulfill requests basis for the model, with five operators: selection, projection 

for data from the functionality server 135. In the preferred 30 (deleting columns from table), product, union (adding the 

embodiment of the present invention, this includes imple- rows of two tables), difference and a composite: join, 

menting the IMS DIV1 CBLTDLI call. This can be decom- Q uery languages based on relational algebra are Struc- 

posed into three tasks: server initialization, CBLTDU call mre d Query Language (SQL) and Query By Example 

resolution, and database access function execution. As dis- ( QBE ), ^th originated by IBM. SQL is usually embedded 

cussed earlier, server initialization is performed on the PCBs a third generation language such as C, called the host 

for the current transaction. Then, the database server language. Because host languages do not typically have 

resolves CBLTDLI database calls. multi-record operations, special SQL commands such as the 

The database server communicates with the database cursor concept are provided to process multi-row query 

through ANSI SQL queries. The database server implements 4Q results in a record-at-a-time fashion. A cursor is a name 

each type of IMS DL/1 function as follows. The database given to a query. When a cursor is opened, the corresponding 

server first validates the arguments to the IMS DL/1 func- query is executed. Any subsequent fetch command on the 

tion. It then dynamically creates an ANSI SQL query string. cursor returns a new row to the host language. When the 

In the preferred embodiment of the present invention, this cursor is closed, query results are no longer available to the 

query string is forwarded to the database using the Oracle 45 host language. Other special commands in SQL embedded 

Call Interface (OCI) from Oracle Corporation. At a high- mode include transaction processing features, dynamic SQL 

level, the process consists in initializing bind and define generation, and authorization control. The physical level 

variables, setting currency information, executing the SQL deals with data dictionaries, data definitions (physical file 

query, and returning query status. structures, file space allocation), storage devices (data 

FIG. 13 is a block diagram of the data storage layer 150 50 compression), access methods (sequential, index-sequential, 

of FIG. 1. The data storage layer 150 is a repository for data direct). 

accessed by the data access layer 140. The user interface Sequential files use a sorted column to perform sequential 

data repository 152 provides user interface objects 153 to the search. Index-sequential adds an index to a given column to 

data access layer 140. The business process data repository provide random access. Large indices may themselves be 

154 provides business processes 155 to the data access layer 55 indexed. Sequential files are difficult to maintain because 

140. The business object data repository 156 provides busi- adding or deleting a record requires reorganization of the 

ness objects 157 to the data access layer 140. The application whole file. Indexed (inverted) files remove the sequential 

data records repository 158 provides data records 159 to the part. Fully inverted refers to indices associated with each 

data access layer 140. column. Indices carry update overhead but enable fast 

FIG. 14 is a schematic diagram of a hardware platform for 60 access. Direct access uses a single key and a calculation 

the data storage layer 150 of FIG. 1. As shown, the data fr° m mat key to locate the physical address of the data in 

storage layer 150 is hosted on a platform that includes a host memory. 

processor 151, with one or more Central Processing Units The distribution discussed in the context of the present 

(CPU), in which the Data Base Management System invention is reduced to process distribution. However, the 

(DBMS) is resident, internal or external storage 153, usually 65 data storage layer can also be distributed among different 

an array of mirrored disks, on which all database data platforms. A decision on how the data can be distributed 

resides, and a terminal console 155 which serves as a human depends on the following four criteria: connectivity, volume, 
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volatility, and usage. The inter-connectivity of the data is rency is handled through locking functions to insure data 

defined by the relations between entities. The volume or size consistency. Data integrity is controllable at the functional- 

of each entity is evaluated in terms of memory usage as well ity layer by the business objects rules or constraints. The 

as number of records. The volatility is the rate of change in underlying database management system usually provides 

the volume of each entity. Finally, the usage is determined 5 data integrity controls implicitly available to applications, 

by the frequency of use of the various screens and the but the usage of such controls are not recommended because 

transaction rate * l wuld mean encoding business logic in the data layer 150 

FIG. 15 is a block diagram of the control layer 160 of FIG. ™ te * o£ < ? nfi ™ g V 0 ^f 0 ^ layer 130 and 

- ™, 4 * . . , J , would therefore be contrary to the fundamental principle of 

1. The control kyer 160 includes utilities for transaction ^ ferred multi . tiered i chitecture . 

management 161, security 162, system admmistration 163, io Communication links 170 m ^ b the other _ 
server management 164 accounting 165 network manage- neQts tQ excQ informatioD b th / of compi f ter 
ment 166 and configuration management 167. These uuli- networks B the of bac ^ round> oon ^ aScT networks 
ties can take the form of libraries or can consist of graphical consist of ^connected collections of autonomous corn- 
user interfaces. puters Networks are dually described in terms of the well 
Transaction management 161 provides library utilities to 15 kn 0wn international Standards Organization (ISO) Open 
manipulate transactions. Transactions are a way to package Systems Interconnection (OSI) reference model. ISO OSI 
related application elements together. Transaction process- describes networking in terms of seven layers, from lowest 
ing refers to the manipulation of groups of elements as to highest: physical, data link, network, transport, session, 
opposed to the manipulation of the individual elements. A presentation, and application. 

transaction that successfully completes the processing of all 20 Because distributed systems are a special case of a 
the elements that compose the transaction is finalized by a net work that is transparent to the application, the present 
database commit, which saves the results of the processing inveDtioQ can re i y on ^ one of the pre valent networking 
of all its elements in a permanent form, usually in the standards. For example, using ISO OSI terminology, one 
database. Should the processing of one of the transaction embodiment of the present invention can be based on the 
elements fail, the transaction elements that have already de fact0 standard M thc lowcst physical md data 
been committed to the database need to be un-committed, hnk levels> a pre f erre d embodiment of the present invention 
and the whole transaction is rolled back, with appropriate can be a standard communication me dia, such as a telephone 
error messages posted. Transaction management 161 is network, local area network (LAN), wide area network 
useful in distributed systems to insure data consistency in (wan) or direct line. Hie Internet Protocol (IP) can be used 
the absence of user-defined integrity constraints. 30 as me network protocol and ^ Tra nsmission Control Pro- 
Security 162 is provided at all layers of an application tocol (TCP) as the transport protocol. Session and presen- 
through a library of functions to manage system as well as tation layers do not exist in the internet model. Application 
data security. At the presentation layer level 110, security protocols include FTP for file transfer, SMTP for electronic 
functions are available at logon time and at the menu, screen, 3$ ma il, an d TELNET for remote login, 
field, and button levels. At the functionality layer 130 level, Because distributed applications are network transparent, 
access to entire servers or to a subset of the services mc distinction lies in the software. Therefore, the preferred 
provided by a server can be restricted. At the data layer 140 embodiment of the present invention uses commercial tools 
level, security functions manage access control lists (ACL), that hide all of the underlying network complexities and 
which enable application administrators to set up a hierarchy applications from network implementations. These 
of user types for controlling access to application resources. tools are based on the Remote Procedure Call (RPC) oper- 
In addition, the underlying database management system ating over TCPAP or over the Distributed Computing Archi- 
usually provides a wide range of security features which are tecture p CE ) mec hanism. Using an RPC, a client program 
implicitly available to the application. performs what looks like a conventional function call. A 
System administration 163 provides graphic facilities for 4S piece of RPC generated code called a client stub handles all 
administrators to perform basic application administration the aspects of handling the call, including packaging the 
tasks, such as lookup table maintenance, user access function arguments for transport, called marshaling, and 
maintenance, and application backup and recovery. carrying out the transport. 

Server management 164 provides mechanisms to orga- On the server side, a similar RPC server stub unpacks the 

nize servers in a hierarchical model in which entities called 50 function arguments, called unmarshaling, and passes them to 

brokers keep track of the servers available to a given client the server code that implements in a conventional way the 

and of their location. This can increase the robustness of function requested by the client. Upon completing the 

applications through server redundancy. execution of the requested function, the server returns the 

Accounting libraries 165 are available to perform logging results of the call to the client in a similar way. Because all 

of application operations at all application tiers for perfor- 55 transport complexities are addressed by the RPC generated 

mance monitoring, auditing, or error tracing and recovery. stubs, RPCs acts just like conventional local calls. 

Logging is also available on a per client, server, or broker For more complex distributed applications, a preferred 

basis. Logging can come in various flavors, with control embodiment of the present invention can use tools based on 

over the level of detail provided or the application resource DCE, which is a more comprehensive distributed system 

or component being monitored. 60 infrastructure that includes directory services, distributed 

Network management 166 provides a graphical interface security, multi-threading, distributed file system, and central 

to monitor clients, servers, and brokers. Network traffic and time management, in addition to RPCs. As sample imple- 

performance can thus be monitored, and network compo- mentation of RPCs effective over both TCP/IP and DCE 

nents restarted automatically or manually upon failure. networks, is the Entera toolkit from Open Environment 

Configuration management 167 provides libraries for a 65 Corporation, 

number of diverse purposes. For instance, application ver- Returning to FIG. 1, the re-architecting system 20 

sion management functions are provided. In addition, cur- includes a user interface conversion utility 210, a procedural 
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language conversion utility 220, and a data definition lan- 
guage conversion utility 230. 

FIG. 16 is a block diagram of the user interface conver- 
sion utility 210 of FIG. 1. The user interface conversion 
utility 210 converts the user interface of an existing appli- 
cation represented by the source user interface definitions 
211 into target user interface definitions 213 using the user 
interface converter 212. In a preferred embodiment of the 
present invention, the source user interface definitions 211 
can be viewed as IMS/VS Message Format Service (MFS) 
files. 

Screen definitions provide structural information about 
the fields that compose the screen layout. Message defini- 
tions provide content information about the fields, such as 
the data they contain and their attributes (protected, 
highlighted, etc.). 

Target user interface definitions 213 can take one of three 
forms: database files 246, a header file 247, and a GUI file 
248. Database files 246 contain the set of statements nec- 
essary to populate user interface repository 152 with screen 
and message information for MFS file 211. In a preferred 
embodiment of the present invention, the database files 246 
can be viewed as ANSI SQL scripts. 

A deletion script removes from the user interface reposi- 
tory 152 any definitions for the MFS file 211. Once this 
repository cleanup is accomplished, an insertion script adds 
to the user interface repository 152 any new definitions for 
the MFS file 211. Consequently, the user interface conver- 
sion utility 210 can be run multiple times for the same MFS 
file without negative effects. In a preferred embodiment of 
the present invention, the user interface repository 152 is a 
standard RDBMS such as Oracle Server 7 from Oracle 
Corporation. 

Information stored in the user interface repository 152 is 
converted at application runtime into the user interface 
representation structures of the presentation layer 116. The 
user interface engine 117 of the presentation layer 110 then 
maps application user interface representation structures 116 
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messages as part of the re-engineering system 30. In a 
preferred embodiment of the present invention, the GUI file 
248 are written in Microsoft Visual Basic. The application 
re-engineering process 30 then uses the GUI file to load 
screen information in Visual Basic, which can be viewed as 
the graphical user interface editor 310, make any modifica- 
tion in Visual Basic, resulting in a modified GUI file, and 
then run a Visual Basic to Oracle conversion process as 
described regarding the graphical user interface editor 310 to 
load the modified GUI file into the user interface repository 
database 152, ready for usage by the application. 

The user interface conversion utility 210 calls the user 
interface converter 212 to generate the "target" representa- 
tion just described. In a preferred embodiment of the present 
invention, the user interface converter 212 is an ANSI C 
program, which takes a MFS file as an input and generates 
output files. To perform this function, the user interface 
converter 212 can be structured using conventional compiler 
technology, including a scanner 241, a parser 243, and a 
code generator 245. 

Specifically, the scanner 241 reads characters from the 
MFS file until a token has been read. The scanner 241 adds 
the token just obtained to a symbol table in which all the 
identifiers of the source language are stored, along with their 
characteristics. The tokens are then passed to the parser 243. 

The parser 243 can be viewed as a function that parses the 
statements of the source language. In this context, the 
delimiter that enables the user interface converter 212 to 
determine when the end of a statement has been reached is 
defined by the particular syntax of the source. Once a 
statement has been parsed, the parser 243 calls another 
function, which returns the type of the statement that has just 
been parsed. This type is then passed to the code generator 
245. 

The code generator 245 can be viewed as a large switch 
that, given a statement type, calls the appropriate function to 
generate "target" code for this statement. The code generator 
245 relies on a library of functions that handle the actual 



into display platform user interface representation structures ^ code generation for the entire set of statements of the source 



50 



118, used by the user interface display platform 115 for 
display to the user. Accordingly, target user interface defi- 
nitions 213 effectively constitute an intermediary user inter- 
face definition language for storage of user interface infor- 
mation in the user interface repository 152 and eventual user 45 
interface representation structures 118. 

Header files 247 are an alternative to database files 246. 
In a preferred embodiment of the present invention, user 
interface representations are stored in the user interface 
repository 152 and retrieved as needed from this repository 
by the business process layer 120. This is an appropriate 
mode of storing a large amount of user interface represen- 
tations on a back-end database host, thus alleviating perfor- 
mance and space constraint problems on the client or 
business process hosts. However, for smaller applications, 
user interface representations may not need to be stored on 
a separate user interface repository 152. Accordingly, a user 
interface converter 212 can generate a header file 247 
instead of database files 246. 

Such a header file 247 is then passed to the business 
process layer 120 to provide information necessary during 
application runtime operations. In this scenario, the header 
file 247 can be viewed as declarative statements in ANSI C 
that are compiled as part of the source code for the business 
process layer 120. 

GUI files 248 are used by application developers and 
maintenance personnel to modify application screens and 



language. One such library exists for each source language, 
with ANSI SQL, ANSI C, and Microsoft Visual Basic as the 
target languages. 

FIG. 17 is a flow diagram of the procedural language 
conversion utility 220 of FIG. 1. The procedural language 
conversion utility 220 converts the functionality and data 
access programs of an existing application into the program- 
ming language targeted for the implementation of the func- 
tionality layer 130 (FIG. 1). This conversion process con- 
sists of two main phases. A first phase (Phase A) converts the 
source language 221 into an intermediary language 225. A 
second phase (Phase B) then transforms the intermediary 
language 225 into the final target language 227. 
The first transformation is executed by a first phase (Phase 
55 A) transformer 224, customized for each source language 
environment 221. The intermediary language 225 is a meta 
language designed to facilitate application maintenance. 

The meta language is independent of source and target 
languages and supports the use of an independent data 
60 dictionary 228. The data dictionary 228 generation is pref- 
erably achieved through the use of data population tools 223, 
which use constructs in the source code and related data 
files. 

The meta language is used as the target for the conversion 
65 of numerous source languages, and in turn can be trans- 
formed into multiple different target languages. The meta 
language is converted to a target language using a second 
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phase (Phase B) transformer 226. There is a specially formed operation, such as a conversion from integer to 

customized second phase transformer program 226 for each floating point, if required. 

target language environment 227. The procedural language i n addition to procedural constructs and data elements and 

conversion utility 220 as a whole is applicable to batch as structures, a subset of the rules specializes in the extraction 

well as on-line applications. 5 and transformation of external data access commands into 

FIG. 18 is an exemplary source code fragment 221 1 . As application-independent external data access commands. In 

illustrated, the source code fragment includes assignment a preferred embodiment of the present invention, 

statements 221-A, 221 -Q221-E, 221 -F, 22 1-H, conditional- application-independent external data access commands 

branch statements 221'-B, 221 f -G, 221'-J, 221-K, 221-M, could be encoded using the ANSI-SQL language. External 

jumps, 221-D, 221-L function calls 221-1, 221-N, and labels 10 data access operations are thus parsed and transformed into 

221-0. The assignment and conditional branch statements separate, application-independent data access commands, 

can use variable values or literals. These generated data access commands are stored in at least 

FIG. 19 is a block diagram of the first phase transformer one separate output file, 

program 224 of FIG. 17. As shown, the main elements of this FIG. 21 is an intermediate language file 225' for the 

transformer are a grammar definition for the source language 1S source code fragment of FIG. 18. The file 225' is created by 

251, a dynamic symbol table generator for the source traversing the parse tree 225 depth-first, left-to-right. A node 

language 252, and a number of rules 253 for transforming a is not output to the file 225' until all children are output. This 

source language 221 to the meta language 225. In addition, technique results in a reverse polish or postfix notation. As 

an external data dictionary 228 contains the data structures, illustrated, each branch 225-1, . . . , 225-8 of the parse tree 

definitions, and common logic constructs pertaining to the 20 225 is represented as a statement 225-1', . . . , 225-8' in the 

source application. file 225*. The trunk nodes of the parse tree 225 are repre- 

In terms of control flow, the first phase transformer 224 sented 355 a terminal statement 225-9*. 

receives a file of source language code 221 as input. This file In summary, executing the transformation rules on the 

is then semantically parsed using the source language gram- source code produces two separate outputs: the transformed 

mar definition 251. A full grammar for the source language source code in a meta language, which is constituted of 

is specified using a programmatic grammar encoding procedural source code and data definition structures, and a 

scheme. set of data access command. 

The symbol table 252 is dynamically generated during FIG. 22 is a block diagram of the second phase trans- 
parsing based on data definitions found in the source code 30 former program 226 of FIG. 17. Similar to the first phase 
221 as well as in the data dictionary 228. All relevant data transformation, the main elements of the second phase 
(i.e. non-procedural) elements found in the source code 221 transformer 226 are a grammar definition 261 for the meta 
are incorporated into the symbol table 252, while irrelevant language 225, a dynamic symbol table generator 262 for the 
elements are discarded based on source language grammar meta language 225, and a number of rules 263 for trans- 
251. The symbol table 252 is thus dynamically built to 35 forming the meta language 225 to a target language 227. In 
contain symbols for all data elements, data structures, data addition, the second phase transformer program 226 uses the 
definitions and variables relevant to the source code file 221 same external data dictionary 228 as does the first phase 
being transformed. transformer program 224. 

FIG. 20 illustrates in FIGS. 20A-20B a parse tree for the In terms of control flow, the second phase transformer 226 

source code fragment of FIG. 18. As illustrated, the source 40 receives as input meta language program files 225, usually 

code 221 is parsed into a series of statement lists 225. Each constituted by meta language procedural source code and 

statement list includes at least one statement. A statement data definition structures files, as well as data access com- 

can include an additional statement list. For example, the Biand fil es > Dom generated by the first phase transformer 

first instruction 221-A (FIG. 18) is parsed into an assignment 224. The meta language program files 225 are then seman- 

(ASSIGN) which assigns the variable (VAR) LOW-VALUE 45 tically parsed using the meta language grammar definition 

to the variable list (VARLIST) of variables (VAR) YMS- 261. A full grammar for the meta language is specified using 

CALL-RESULT and FLAG-AREA. Each source language a programmatic grammar encoding scheme, 

instruction 221-A, . . . , 221-0 of FIG. 18 is represented as The symbol table 262 is dynamically generated during 

a respective branch cluster 223 -A, . . . , 225-0 on the parse parsing based on data definitions found in the meta code 225 

tree 225 of FIG. 20. The branch clusters are on branches 50 as well as in the data dictionary 228. 

225-1, . . . , 225-8 of the parse tree 225. From this The data access command files portions of the meta 

representation, the source language is converted to the language program files 225 provided as input are parsed 

intermediate language. using a different mechanism. Because this mechanism is a 

Once parsing is complete, a complete set of rules 253 for simplified version of the one used for procedural source 
transforming source language code to meta language code is 55 code and because it is based on the exact same principles, it 
programmed as declarative rules in a separate conversion will not be detailed any further here, 
routine 253. The conversion rules 253 operate as follows. A Upon completion of parsing, a complete set of rules 263 
rule is applied to each source language construct parsed for transforming the meta language code 225 to the target 
using the grammar 251. When a rule is executed, a source language code 227 is programmed as declarative rules in a 
language construct is transformed to its equivalent construct 60 separate conversion module 263. The conversion rules 263 
in the meta language. Procedural constructs and primitives includes rules for transforming meta language data defini- 
are thus regenerated in the meta language. Operations on tions into target language data structures, rules for trans- 
data elements and data structures are first validated using the forming meta language variable definitions into target lan- 
symbol table 252. Based on this validation, an equivalent guage variables, rules for generating target language 
operation is custom-generated in the meta language. The 65 initialization routines for the data structures and variables 
rule being executed for this validation operation generates a mentioned above, rules for transforming procedural meta 
specific construct to reproduce the semantics of the trans- language source code into target language source code, and 
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optionally rules for customizing the application-independent 
data access commands for a particular application such as 
Oracle. A rule is applied to each language construct parsed 
using the meta language grammar 261. 

Language constructs include: data definitions, variable 
definitions, and procedural constructs. Data definitions in 
meta language code are transformed into target language 
data structures by executing a set of rules written for this 
purpose. Variable definitions in meta language are also 
transformed into target language variables by executing a set 
of rules written for that purpose. For each variable definition 
created, an initialization routine is created. Procedural con- 
structs are transformed into their equivalent in the target 
language. Data access commands can be tailored for a 
particular application as required by the target environment. 
Executing the transformation rules on the meta language 
source code produces output files containing the transformed 
code in the target language: procedural source code files, 
data definition structure files, and final data access command 
files. 

The target source code 227 includes calls to specially 
designed and implemented libraries to support functionality 
that is not provided natively in the new target environment. 
These functions include variable handling, value 
assignment, data access services, transaction processing, and 
other. Depending on the target environment, different runt- 
ime libraries are required in order to guarantee correct 
execution in the new environment. The scope of these 
libraries is determined not only by the target environment, 
but also by the source environment. All source constructs 
must be mapped to equivalent constructs in the target 
environment. 

FIGS. 23A-23B are C and C++ target code fragements 
227', 227", respectively, for the source code fragment of 
FIG. 18. As illustrated, the intermediate language illustrated 
in the output file 225' of FIG. 21 is transformed into a select 
target language source code 227. The target language can be 
any procedural programming language (such as C) or any 
object-oriented programming language (such* as C++). As 
described, a different second phase transformer program 226 
is used to generate source code in each target language. 

Together with the transformation of the code to the target 
environment, the transformation process permits new data 
organization methods. If new methods are used to organize 
data, additional libraries might be required to achieve com- 
plete compliance with the original application behavior. An 
example of specialized library for IMS/VS data organization 
method was outlined above in the context of the data access 
layer 140. 

In addition to the transformed code and required libraries, 
a runtime infrastructure must be provided for application 
execution. The infrastructure in question corresponds to the 
multi-tiered architecture 10 detailed above. Because the 
description of the architecture 10 focused on on-line 
programs, a number of key differences should be noted in its 
application to the batch components of applications. Batch- 
related code modules only interact with their calling process, 
eliminating the need to maintain a two-way communication 
structure with the user interface module and the accompa- 
nying state information in the business layer. Instead, 
re-architected batch processes are stand-alone programs 
constituted by a wrapper that provides means to parse the 
input arguments and call the top-level batch job. Typically, 
this top-level batch job requires some form of job scheduling 
infrastructure. As an example, legacy Job Control Language 
(JCL) can be converted to a scripting language-equivalent 
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such as UNIX shell, Perl, or REXX. The resulting script then 
calls the various batch programs, interleaved with scripting 
commands or library calls that provide functionality that is 
similar to that of the source legacy system. In spite of these 
5 differences, batch conversion and processing follows the 
same fundamental principles as on-line, in a simplified 
manner. Consequently, a frill discussion of the specifics of 
batch conversion and runtime execution will not be detailed 
any further. 

10 FIG. 24 is a block diagram of the data definition language 
conversion utility 230 of FIG. 1. The database conversion 
utility 230 is used to convert a source database language 231 
into a target database language 237 using a database con- 
verter 234. As illustrated, the conversion must address the 

15 database structure, encoded using a Data Definition Lan- 
guage (DDL), and referred to as a schema, as well as the 
database data. 

In a preferred embodiment of the present invention, the 
target DDL 238 is a relational database schema specified 

20 using conventional ANSI SQL language. Such a schema 
defines the tables that compose an application, along with 
their key fields, and other descriptive fields. Initial values 
and other constraints such as referential integrity clauses 
may also be included in this schema. Because relational 

25 schemas are well understood, and ANSI SQL syntax is 
well-documented, the primary task of the DDL converter 
235 is to map the syntax of source DDL 232 to the 
corresponding ANSI SQL syntax. In a preferred embodi- 
ment of the present invention, this "target" DDL 238 can be 

30 viewed as an intermediary language that can then be con- 
verted to the final target DDL language for increased main- 
tainability and flexibility, as was the case with the user 
interface and procedural language conversion utility. For 
illustrative purposes, IMS DL/1 can be considered as the 

35 source DLL 232. 

FIG. 25 is a block diagram illustrating a schema conver- 
sion. As shown, the DDL converter 235 is sub-divided into 
a first converter 235a and a second converter 232ft. The first 

^ converter 235a takes DBDxx 232a, DBDxx 232ft, and 
COPYLIB 235c as inputs and generates a table creation SQL 
statement file 238a, an index creation SQL statement file 
238ft, a primary key creation SQL statement file 238c, and 
a database schema ANSI C header file 238c£ 

45 By way of background, an IMS database schema depends 
on Data Base Descriptions (DBD) and COBOL copy librar- 
ies (COPYLIB). All IMS data bases must be defined through 
DBD generation prior to use by application programs. A 
DBD is the DL/1 control block that contains all the infor- 

50 mation necessary to describe a data base, namely segment 
types, physical and logical relationships between segment 
types, database organization and access method, and physi- 
cal characteristics of the database. COPYLIB contains 
COBOL data structures definition and is used to create 

55 corresponding C structures and IMS segment definitions. 
The first converter 235a generates a table file 238a, which 
is used to create tables in the target RDBMS. The table file 
238a includes simple relational table creation statements, 
without indices, keys, or reference integrity. Consequently, 

60 it an be generated directly from COPYLIB 232c 
information, without any DBD input. For example, the 
COPYLIB entry for a segment is used to generate a corre- 
sponding relational table. 
A relational table is build from an IMS segment as 

65 follows. First, all the key fields of all the ancestors of the 
segment in question in the IMS hierarchy are included in the 
relational table into which the segment in question is being 
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converted. Then, all the local key fields of the segment being In IMS, some numerical field are compressed into a binary 

converted are included in the target relational table. Finally, representation for storage efiSciency. Such packed data still 

all the local non-key fields of the segment to convert are present in binary format in data flat files 231ft, is first 

added to the target relational table. unpacked and then moved to the end of the record, before 

The first converter 235a also generates the index file 238ft 5 using a filler, namely clearing the packed data original 

and the primary key file 238c, which are derived from the positions with blanks. When a data loading pattern file 231a 

table file 238a. The first converter 235a creates one index for specifies packed data fields, the data converter 236 searches 

each parent of the converted segment by concatenating the the end of the record instead of the original field position to 

keys for that parent. One index is also created for each local locate the proper data in unpacked format, 

key field. io Another peculiar situation arises with redefined fields. 

The first converter 235a also creates the schema header COPYLIB 232c sometimes specifies a redefinition for one 

file 238a* having information for each segment using the or more fields. Such re-definitions are ignored and left to the 

DBDxx 232a and corresponding DBDxxL 2326 to provide functionality code to handle. When redefined fields include 

schema information to application programs. Preferably, a packed data however, the data converter 236 creates one 

segment header file includes two ANSI C data structures: a 1S filler for each redefine after moving all unpacked data for the 

segment and a segment array. The segment structure redefine in question to the end of record. Combination 

includes the following information: a segment name, the between re-definitions and packed data fields is thus treated 

names of the segment columns, the segment child index in as a special case of the latter. 

the form of another header file, the length of each segment Once all conversion is complete and all output files are 
column, the expanded column length, the PIC mask for each 20 available, the order of creation for a given target database 
segment column indicating column type and size, the col- table is first to create the table using the table creation file 
umn usage, a logical key and the corresponding local key 238a, next load the data from the target data 239, then create 
index, the number of columns in the segment, the number of the primary key using the primary key creation file 238c, and 
parent keys in the segment, and the number of local keys for finally to create the indices from the index creation file 238ft. 
this segment. The segment array structure includes the 25 Once the target database structure is established and all 
following information: a segment name, physical child database data is loaded, the ANSI C structures in the schema 
names, the number of children, a logical flag, and a pointer header file 238d and the PSB header file 238e are used at 
to the corresponding segment data structure. runtime by application programs to access the target data- 
in addition to the first converter 235a, the second con- base structures, 
verter 2356 is used to convert PSB definitions 232a* into PSB 30 As mentioned previously with regard to FIG. 1, the 
header files 238e. As mentioned previously, a PSB defines custom and re-engineering system 30 focuses on providing 
the database which can be accessed, the segments within the an enterprise a facility for maintaining and enhancing dis- 
database which are available, and the type of access (read, tributed infrastructure. Even though this facility is an inte- 
update, etc.) which can occur. The PSB header file 23&> 3$ gr a l part of the overall system of the present invention, it is 
provides such database access information to application really an add-on facility that becomes paramount once the 
programs. transition is complete. Consequently, only an overview of 
FIG. 26 is a block diagram of a converter 235a, 2356 of the custom and re-engineering system 30 will be provided 
FIG. 25. Both converters 235a, 235ft are built using the here. At a high-level therefore, the custom and 
conventional principles of compiler design. This includes a ^ re-engineering system 30 includes a graphical user interface 
scanner 271 to decompose source data definition language editor 310, a graphical business process editor 320, a graphi- 
232 into tokens 272, a parser 273 to assemble tokens 272 cal business object editor 330, a graphical data record editor 
into a syntactic parse tree 274, and a code generator 275 to 340, a logic development environment 350, and facilitation 
generate target data definition language constructs 238 from tools 360. 

the parse tree 274. This technology is well-understood and 45 graphical editors 310, 320, 330, 340 are preferably 

documented in existing literature and the details of a par- fourth generation languages (4GL) or Computer Aided Soft- 

ticular compiler are highly dependent on the source and ware Engineering (CASE) tools that facilitate the applica- 

target languages. Consequently, the converters 235a, 235ft ti on development task by enabling a certain amount of the 

will not be detailed any further. application code to be generated automatically from graphi- 

Once the database structure is converted, the next task is 50 cal representations. In particular, the graphical user interface 

to convert and load database data. In the IMS example, editor 310 can be a commercially available user interface 

source data 233 is stored in a hierarchical fashion. The first display platforms or GUI builders discussed in the context of 

converter 235a generates a data loading pattern file the presentation layer 110. 

DBDxx.dlp 238/ for a given physical DBD using DBDxx F1G . 28 is a block diagram of the graphical user interface 

232a and COPYLIB 232c information. 55 editor 310 Q f FIG. 1. The graphical user interface editor 310 

FIG. 27 is a block diagram of the data converter 236 of is a typical user interface made to create menus and paint 

FIG. 24. ADBDxx.dlp file 231a is provided as input to the screens. As such, the graphical user interface editor 310 

data converter 236, along with a flat file 231ft that contains includes a screen editor 311 to position graphical represen- 

the data to be converted. The data converter 236 uses the tations of business objects on a screen or form. Screens can 

data loading pattern specified in the DBDXX.dlp file 231a eo thus include text fields, labels, buttons, selection boxes, pull 

to determine the desired target format for each data record down lists, and similar graphical objects that compose a user 

in the data flat file 231ft and generate an ANSI SQL file 239a interface. These graphical representations of business 

containing the INSERT statements necessary to populate the objects can be grouped so that a screen can be composed of 

target database with the data provided. sub-screens. This is useful to represent screen overlays, 

The data converter 236 needs to take into account a 65 which are screens that have a fixed area as well as a variable 

number of technical issues in performing its task on IMS area that changes depending on user actions. Sub-screens are 

data, including packed data handling and field redefinition. also useful for grouping together business objects that need 
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to be displayed across a number of application screens. The 
screen editor 311 creates internal user interface representa- 
tions 312 which are processed by a user interface code 
generator 313 into data stored in the user interface repository 
152. 

FIG. 29 is a block diagram of the graphical business 
process editor 320 of FIG. 1. The graphical business process 
editor 320 is a tool that enables application developers to 
represent the business processes that an application is meant 
to automate in a more intuitive, graphical form, referred to 
as a process flowchart. Because a business process can be 
broken down into sub-processes, an application can be 
viewed as a hierarchy of process flowcharts. This modular- 
ization enables an application to look at high-level business 
processes separately from detailed business sub-processes. 
As illustrated, a business process editor 321 generates inter- 
nal business process representations 322, which are con- 
verted by a business process code generator 323 into data 
stored in the business process repository 154. 

In a preferred embodiment of the present invention, 
process flowcharts can be viewed as conventional transition 
diagrams. Transition diagrams are networks of nodes rep- 
resented graphically by circles and are called states. The 
states are connected by directed labeled arrows, called 
edges. Edge labels represent the transformations that lead 
from one state to the next. 

As an example, the process of applying for a driver's 
license includes routing a driver's license application paper 
form through the various departments in charge of eye 
exams, written test, driving test and the like, with a pro- 
gression from department to department This process can be 
modeled using a transition diagram in which the states 
represent the various departments, and the edges represent 
the changes to the electronic driver's license form that need 
to be performed before that form is routed to the next 
department. 

A transition diagram can be deterministic, or non- 
deterministic, where non-deterministic means that more than 
one edge with the same label impossible out of a state. In a 
preferred embodiment of the present invention, non- 
deterministic transition diagrams are used to represent busi- 
ness processes graphically. These non-deterministic transi- 
tion diagrams constitute a process representation perfectly 
suited for interpretation by business process engine 124 
(FIG. 8), which, as mentioned earlier, is the event handler 
based on NFA theory that processes the business process 
flowcharts resulting from the graphical business process 
editor 320. 

FIG. 30 is a block diagram of the graphical business 
object editor 330 of FIG. 1. The graphical business object 
editor 330 is a tool that enables the graphical editing of 
business objects and their relationships. A business object 
editor 331 generates internal business object representations 
which are converted by a business object code generator into 
data stored in the business object repository 156. 

In a preferred embodiment of the present invention, the 
graphical business object editor 330 can be viewed as a 
Entity-Relationship (ER) diagramming tool. The ER data 
model is the predominant conceptual level description tool 
and is used as a diagramming technique where rectangles 
represent entities, circles represent attributes, diamonds rep- 
resent relationships. This graphical ER diagram can be used 
to generated automatically the application database schema, 
and a number of the basic data accessor queries. 

In addition, default constraints can be automatically asso- 
ciated to business objects based on the business object type. 
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This can lead to automatic generation of maintenance 
screens for lookup business objects that can take a known 
range of values. The graphical business object editor can 
also be used to create templates that can be reused through- 

5 out an application. For instance, every screen may have a 
number of fixed function keys or buttons such as display, 
insert, delete, update, clear, refresh, backup, or quit, as well 
as a number of variable function keys whose semantics 
change from screen to screen. These function keys can be 

10 treated as a group and provided automatically as part of the 
template for every screen in an application. 

FIG. 31 is a block diagram of the graphical data record 
editor 340 of FIG. 1. The graphical data record editor 340 is 
a tool that provides access to the data stored in the relational 

15 tables of the data layer RDBMS, As such, it is an interface 
that provides graphical access to each application table and 
permits the application developer or maintainer to view, 
insert, delete or update specific data records. As illustrated, 
a data record editor 341 generates internal data record 

20 representations 342 which are converted by a data record 
code generator 343 into data stored in the data record 
repository 158. 

This focus on application data is complemented by an 
ability to manipulate DDL structures. In this function, the 

25 data record editor can be viewed as a data repository used to 
generate the database schema, either initially in its totality, 
or subsequently, for incremental updates. In this regards, the 
data record editor is similar to commercially-available off- 
the-shelve packages such as PeopleSoft Inc.'s Record Editor 

30 or ERwin from Logic Works Corporation. As a whole, the 
data record editor greatly facilitates application maintenance 
and data error recovery for day to day application 
development, maintenance, and operation. 

35 FIG. 32 is a block diagram of the logic development 
environment 350 of FIG. 1. The logic development envi- 
ronment 350 is an environment that adheres to the "open 
system" standards. As defined herein, an open system is a 
system that implements sufficient open specifications for 

40 interfaces, services, and supporting formats to enable prop- 
erly engineered application software to be ported across a 
wide range of systems with minimal changes, to interoperate 
with other applications on local and remote systems, and to 
interact with users in a style which facilitates user portabil- 

45 ity. Open specifications are defined herein as a public 
specification that is maintained by an open, public consensus 
process to accommodate new technology over time and that 
is consistent with standards. 

Functionality, the logic development environment 350 

50 includes, at a minimum, an operating system 351, a third 
generation programming language compiler 352 and debug- 
ger 353, a runtime building facility 354, a source control 
system 355, and a screen oriented text editor 356. One 
possible embodiment of the logic development environment 

55 could use the UNIX operating system, the ANSI C program- 
ming language, the XDB debugging facility, the MAKE 
build utility, the RCS revision control system, and the 
EMACS text editor. 

FIG. 33 is a schematic block diagram of the facilitation 

60 tools 360 of FIG. 1. The facilitation tools 360 are graphic 
editing tools. The primary concept is to provide a structured, 
yet flexible, methodology for gathering user and application 
requirements while enabling the use of the resulting docu- 
mentation to automatically generate a number of the archi- 

65 tectural constructs that would otherwise have to be encoded 
manually. These facilitation tools 360 can include project 
tools 361, organizational tools 362, communication tools 
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363, office tools 364, groupware tools 365, and templates 

366 for processing user inputs. 

Equivalents 

While this invention has been particularly shown and 
described with reference to preferred embodiments thereof, 
it will be understood by those skilled in the art that various 
changes in form and details may be made therein without 
departing from the spirit and scope of the invention as 
defined by the appended claims. In particular, the invention 
is not limited to particular communications links, protocols, 
data structure formats, etc. In addition, although various 
features of the invention are disclosed as being either 
hardware or software, it is understood that any feature of the 
invention can be embodied in hardware, software or firm- 
ware. 

These and all other equivalents are intended to be encom- 
passed by the following claims. 
What is claimed is: 

1. A system to transition legacy applications operable on 
a legacy computing system to a distributed infrastructure, 
the system comprising: 

a multi-tiered computer architecture including a process 
control tier for modeling an internal work flow of an 
enterprise and a functionality tier for performing work 
in accordance with the work flow of the enterprise; and 

a legacy application inoperable on the multi-tiered com- 
puter architecture and 

an automated converter to transition the legacy applica- 
tion to a target application operable on the multi-tiered 
computer architecture. 

2. The system of claim 1 wherein the multi-tiered com- 
puter architecture is a client-server architecture having at 
least four tiers. 

3. The system of claim 1 where the multi-tiered architec- 
ture further includes a presentation tier for interfacing with 
a user, a data retrieval tier, and a data storage tier. 

4. The system of claim 1 wherein the converter includes 
an intermediate language, the language of the legacy appli- 
cation being translated to the intermediate language and 
from the intermediate language to the language of the target 
application. 

5. The system of claim 1 wherein the target application is 
an internet accessible application. 

6. The system of claim 1 wherein the target application is 
an object-oriented application. 

7. The system of claim 1 further comprising an imple- 
mentation plan which provides a prioritized list of legacy 
applications to be transitioned by the automated converter. 

8. The system of claim 7 wherein the implementation plan 
further provides instructions for controlling the operation of 
the automated converter. 

9. The system of claim 1 further comprising an imple- 
mentation strategy which identifies inputs to a target system 
and provides a list of action items for obtaining the identified 
outputs from the legacy computing system. 

10. A method for transitioning legacy applications oper- 
able on a legacy computing system to a distributed 
infrastructure, comprising the steps of: 

providing a multi-tiered architecture including a process 
control tier for modeling an internal work flow of an 
enterprise and a functionality tier for performing work 
in accordance with the work flow of the enterprise; and 

providing a legacy application inoperable on the multi- 
tiered computer architecture; and 

in a computer, automatically converting the legacy appli- 
cation to a target application operable on the multi- 
tiered computer architecture. 
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11. The method of claim 10 wherein the step of providing 
a multi-tiered architecture comprises providing a client- 
server architecture having at least four tiers. 

12. The method of claim 10 where the multi-tiered 
5 computer architecture further includes a presentation tier for 

interfacing with a user, a data retrieval tier, and a data 
storage tier. 

13. The method of claim 10 wherein the step of converting 
comprises translating the language of the legacy application 

to to an intermediate language and translating the intermediate 
language to the language of the target application. 

14. The method of claim 10 wherein the target application 
is an internet accessible application. 

15. The method of claim 10 wherein the target application 
15 is an object-oriented application. 

16. The method of claim 10 further comprising the step of 
providing a prioritized list of legacy applications to be 
transitioned by the automated converter. 

17. The method of claim 16 further comprising the step of 
20 controlling the operation of the automated converter based 

on the prioritized list. 

18. The method of claim 10 further comprising the steps 
of: 

identifying inputs to a target system including the target 
25 application; and 

obtaining the identified outputs from the legacy applica- 
tions from a list of action items. 

19. In a computer, a converter for translating a legacy 
program component operating in a legacy language on a 

30 legacy computing system to a target program component 
operating in a target language on a distributed infrastructure 
includes a process control tier and a functionality tier, the 
converter comprising: 
35 an intermediate language; 

a first converter for translating the legacy program com- 
ponent from the legacy language to an intermediate 
component in the intermediate language wherein the 
legacy language is operable on a legacy processor, and 
4Q a second converter for translating the intermediate com- 
ponent from the intermediate language to the target 
program component in the target language wherein the 
target language is operable on a target processor dif- 
ferent from the legacy processor. 
45 20, The converter of claim 19 wherein the intermediate 
language is independent of the legacy language and the 
target language. 

21. The converter of claim 19 wherein the intermediate 
language is inoperable on either the legacy processor or the 

50 target processor. 

22. The converter of claim 19 wherein the first converter 
parses the legacy program component into a parse tree, the 
intermediate component representing the parse tree in a 
postfix notation. 

5S 23. In a computer, a method for translating a legacy 
program component operating in a legacy language on a 
legacy computing system to a target program component 
operating in a target language on a distributed infrastructure 
includes a process control tier and a functionality tier, 
60 comprising the steps of: 

defining an intermediate language; 
in a first converter, translating the legacy program com- 
ponent from the legacy language to an intermediate 
component in the intermediate language wherein the 
65 legacy language is operable on a legacy processor, and 
in a second converter, translating the intermediate com- 
ponent from the intermediate language to the target 
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program in the target language wherein the target 
language is operable on a target processor different 
from the legacy processor. 

24. The method of claim 23 wherein the intermediate 
language independent of the legacy language and the target 
language. 

25. The method of claim 23 wherein the intermediate 
language is inoperable on either the legacy processor or the 
target processor. 

26. The method of claim 23 wherein the step of translating 
the legacy program component comprises: 

parsing the legacy program component into a parse tree; 
and 

representing the parse tree in a postfix notation. 

27. A system to transition legacy applications operable on 
a legacy computing system to a distributed infrastructure, 
the system comprising: 

a multi-tiered computer architecture including a process 
control tier for modeling an internal work flow of an 
enterprise and a functionality tier for performing work 
in accordance with the work flow of the enterprise; and 

an automated converter having a first converter and a 
second converter to transition a legacy application to a 
target application operable on the multi-tiered com- 
puter architecture, the first converter translating the 
legacy application from a legacy language to an inter- 
mediate language and the second converter translating 
the translated legacy application from the intermediate 
language to the target application in a target language. 

28. The system of claim 27 wherein the multi-tiered 
computer architecture is a client-server architecture having 
at least four tiers. 

29. The system of claim 27 where the multi-tiered com- 
puter architecture further includes a presentation tier for 
interfacing with a user, a data retrieval tier, and a data 
storage tier. 

30. The system of claim 27 wherein the intermediate 
language is independent of the legacy language and the 
target language. 

31. The system of claim 27 wherein the target application 
is an internet accessible application. 

32. The system of claim 27 wherein the target application 
is an object-oriented application. 

33. The system of claim 27 further comprising an imple- 
mentation plan which provides a prioritized list of legacy 
applications to be transitioned by the automated converter. 

34. The system of claim 33 wherein the implementation 
plan further provides instructions for controlling the opera- 
tion of the automated converter. 

35. The system of claim 27 further comprising an imple- 
mentation strategy which identifies inputs to a target system 
including the target applications and provides a list of action 
items for obtaining the identified outputs from the legacy 
applications. 

36. A method for transitioning legacy applications oper- 
able on a legacy computing system to a distributed 
infrastructure, comprising the steps of: 

providing a multi-tiered computer architecture including a 
process control tier for modeling an internal work flow 
of an enterprise and a functionality tier for performing 
work in accordance with the work flow of the enter- 
prise; and 

in a computer, automatically converting a legacy appli- 
cation to a target application operable on the multi- 
tiered computer architecture, the legacy application 
translated from a legacy language to an intermediate 
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language and the translated legacy application being 
translated from the intermediate language to the target 
application in a target language. 

37. Trie method of claim 36 wherein the step of providing 
5 comprises providing a client-server architecture having at 

least four tiers. 

38. The method of claim 36 where the multi-tiered 
computer architecture further includes a presentation tier for 
interfacing with a user, a data retrieval tier, and a data 

1Q storage tier. 

39. The method of claim 36 wherein the step of converting 
comprises defining the intermediate language to be indepen- 
dent of the legacy language and the target language. 

40. The method of claim 36 wherein the target application 
is an internet accessible application. 

15 41 . The method of claim 36 wherein the target application 

is an object-oriented application. 

42. The method of claim 36 further comprising the step of 

prioritizing a list of legacy applications to be transitioned by 

the automated converter. 
20 43. The method of claim 42 further comprising the step of 

controlling the operation of the automated converter based 

on the prioritized list 

44. The method of claim 36 further comprising the steps 
of: 

25 identifying inputs to a target system including the target 
application; and 
obtaining the identified outputs from the source applica- 
tions using a list of action items. 

45. A system for transitioning a legacy application oper- 
30 able on a legacy computing system to a distributed infra- 
structure includes a process control tier and a functionality 
tier, the system comprising: 

an intermediate language; 
35 a first converter for translating the legacy application 
component from a legacy language to an intermediate 
component in the intermediate language wherein the 
legacy language is operable on a legacy processor, and 
a second converter for translating the intermediate com- 
4Q ponent from the intermediate language to a target 
application component in a target language operable on 
the distributed infrastructure wherein the target lan- 
guage is operable on a target processor different from 
the legacy processor. 
45 46. The system of claim 45 wherein the intermediate 
language is independent of the legacy language and the 
target language. 

47. The system of claim 45 wherein the intermediate 
language is inoperable on either the legacy processor or the 

5 q target processor. 

48. The system of claim 45 wherein the first converter 
parses the legacy program component into a parse tree, the 
intermediate component representing the parse tree in a 
postfix notation. 

55 49. The system of claim 45 further comprising a multi- 
tiered computer architecture. 

50. A method for transitioning a legacy application oper- 
able on a legacy computing system to a distributed infra- 
structure includes a process control tier and a functionality 
60 tier, comprising the steps of: 

defining an intermediate language; 
in a first converter, translating the legacy application 
component from a legacy language to an intermediate 
component in the intermediate language wherein the 
65 legacy language is operable on a legacy processor, and 
in a second converter, translating the intermediate com- 
ponent from the intermediate language to a target 



11/17/2003, EAST Version: 1.4.1 



5,960 

application component in a target language operable on 
the distributed infrastructure wherein the target lan- 
guage is operable on a target processor different from 
the legacy processor. 

51. The method of claim 50 wherein the intermediate 5 
language independent of the legacy language and the target 
language. 

52. The method of claim 50 wherein the intermediate 
language is inoperable on either the legacy processor or the 
target processor. 
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53. The method of claim 50 wherein the step of translating 
the legacy program component comprises: 

parsing the legacy program component into a parse tree; 
and 

representing the parse tree in a postfix notation. 

54. The method of claim 50 further comprising the step of 
operating the target program on a multi-tiered computer 
architecture. 

***** 



11/17/2003, EAST Version: 1.4.1 



ilillllllllllllllllllllll 

US006269396B1 

(12) United States Patent ao) Patent No.: us 6,269,396 bi 

Shah et al. (45) Date of Patent: Jul. 31, 2001 



(54) METHOD AND PLATFORM FOR 

INTERFACING BETWEEN APPLICATION 
PROGRAMS PERFORMING 
TELECOMMUNICATIONS FUNCTIONS AND 
AN OPERATING SYSTEM 

(75) Inventors: Mahesh V. Shah, Piano; David W. 

McDaniel, Dallas; James R. Vatteroni, 
Allen; Stephen B. Jaggers, Allen; 
Mark E. Woriine, Allen, all of TX 
(US) 

(73) Assignee: Alcatel USA Sourcing, L.P., Piano, TX 
(US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 09/211,016 

(22) Filed: Dec. 11, 1998 

Related U.S. Application Data 

(60) Provisional application No. 60/069,576, filed on Dec. 12, 
1997. 

(51) Int. CI. 7 G06F 13/00 

(52) U.S. CI 709/223 

(58) Field of Search 379/113, 201, 

379/242; 709/200, 220, 221, 222, 223-224 

(56) References Cited 

U.S. PATENT DOCUMENTS 

5,940,487 * 8/1999 Bunch et al 379/201 

FOREIGN PATENT DOCUMENTS 
93205508 10/1993 (WO) G06F/9/40 



9707638 2/1997 (WO) H04Q/3/00 

9724837 7A997 (WO) H04I712/24 

9731451 8/1997 (WO) H041712/24 

OTHER PUBLICATIONS 

Maltini, et al. "OSI System and Application Management: 
an Experience in a Public Administration Context", pp. 
492-500, Apr. 492-500, Apr. 15, 1996, IEEE. 

* cited by examiner 



Primary Examiner — Robert B. Harrell 

(74) Attorney, Agent, or Firm — Baker Botts L.L.P. 



(57) 



ABSTRACT 



A method of providing a software interface between appli- 
cation programs performing telecommunications functions 
and an operating system running on at least one node at a site 
supporting the application programs, and further forming an 
interface between the application programs and a telecom- 
munications network is provided. The method includes 
providing a network platform manager operable to remove 
nodes from service, restore nodes to service, remove appli- 
cations from service, and restore applications to service, 
providing a network system integrity manager operable to 
monitor the nodes and to enable failed nodes to recover, 
providing a configuration manager operable to interface with 
a host coupled to the telecom platform, providing a node 
platform manager operable to provide management func- 
tions for a node, providing a service manager operable to 
start and stop processes at the direction of the node platform 
manager, and providing a node system integrity manager 
operable to monitor inter-node links. 

42 Claims, 21 Drawing Sheets 
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METHOD AND PLATFORM FOR 
INTERFACING BETWEEN APPLICATION 
PROGRAMS PERFORMING 
TELECOMMUNICATIONS FUNCTIONS AND 

AN OPERATING SYSTEM 5 

RELATED APPLICATION 

This patent application claims benefit from provisional 
patent application No. 60/069,576, filed on Dec. 12, 1997, 
and entitled Telecom Platform System and Method. 

TECHNICAL FIELD OF THE INVENTION 

This invention is related in general to the field of tele- 
communications. More particularly, the invention is related 15 
to a telecom platform system and method. 

SUMMARY OF THE INVENTION 

In one aspect of the present invention, a telecom platform 2Q 
forming an interface between application programs perform- 
ing telecommunications functions and an operating system 
running on at least one node at a site supporting the 
application programs, and further forming an interface 
between the application programs and a telecommunications 25 
network. The telecom platform includes network manage- 
ment processes operable to provide inter-node configuration, 
monitoring and management functionality, node manage- 
ment processes operable to provide node initialization, 
configuration, monitoring, and management functionality, 3Q 
event processes operable to provide initialization, 
termination, and distribution of tasks in response to prede- 
termined events, common processes operable to provide a 
library of a plurality of programming tools for the develop- 
ment of the application programs, communications pro- 35 
cesses operable to provide message handling functionality, 
and distributed object processes operable to provide a dis- 
tributed database repository for object-based communica- 
tions. 

In another aspect of the present invention, a method of 40 
providing a software interface between application pro- 
grams performing telecommunications functions and an 
operating system running on at least one node at a site 
supporting the application programs, and further forming an 
interface between the application programs and a telecom- 45 
munications network is provided. The method includes 
supplying network management processes operable to pro- 
vide inter-node configuration, monitoring and management 
functionality, supplying node management processes oper- 
able to provide node initialization, configuration, 50 
monitoring, and management functionality, supplying event 
processes operable to provide initialization, termination, and 
distribution of tasks in response to predetermined events, 
supplying common processes operable to provide a library 
of a plurality of programming tools for the development of 55 
the application programs, supplying communications pro- 
cesses operable to provide message handling functionality, 
and supplying distributed object processes operable to pro- 
vide a distributed database repository for object-based com- 
munications. 60 

In yet another aspect of the present invention, a method of 
providing a software interface between application pro- 
grams performing telecommunications functions and an 
operating system running on at least one node at a site 
supporting the application programs, and further forming an 65 
interface between the application programs and a telecom- 
munications network is provided. The method includes 



providing a network platform manager operable to remove 
nodes from service, restore nodes to service, remove appli- 
cations from service, and restore applications to service, 
providing a network system integrity manager operable to 
monitor the nodes and to enable failed nodes to recover, 
providing a configuration manager operable to interface with 
a host coupled to the telecom platform, providing a node 
platform manager operable to provide management func- 
tions for a node, providing a service manager operable to 
start and stop processes at the direction of the node platform 
manager, and providing a node system integrity manager 
operable to monitor inter-node links. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a better understanding of the present invention, ref- 
erence may be made to the accompanying drawings, in 
which: 

FIG. 1 is a simplified block diagram of the telecom 
platform architecture layers according to an embodiment of 
the present invention; 

FIG, 2 is a simplified block diagram of the telecom 
platform conceptual components according to an embodi- 
ment of the present invention; 

FIG. 3 is a block diagram of telecom platform's concep- 
tual components and relationships therebetween according 
to an embodiment of the present invention; 

FIG. 4 is a simplified block diagram of the logical 
partitioning of the telecom platform according to an embodi- 
ment of the present invention; 

FIG. 5 is a simplified block diagram of the telecom 
platform services and their dependencies according to an 
embodiment of the present invention; 

FIG. 6 is a simplified block diagram of the physical 
partitioning of the telecom platform according to an embodi- 
ment of the present invention; 

FIG. 7A is a block diagram of NetPM's testing flow 
according to an embodiment of the present invention; 

FIG. 7B is a block diagram of NetPM's time synchroni- 
zation flow according to an embodiment of the present 
invention; 

FIG. 7C is a block diagram showing fault detection and 
interaction between network management services and node 
management services according to an embodiment of the 
present invention; 

FIG. 7D is a block diagram showing interaction between 
core services according to an embodiment of the present 
invention; 

FIG. 8 is a state transition diagram of telecom platform 
nodes according to an embodiment of the present invention; 

FIG. 9A is a simplified block diagram of node start up 
process according to an embodiment of the present inven- 
tion; 

FIG. 9B is a message flow diagram of node initialization 
process according to an embodiment of the present inven- 
tion; 

FIG. 9C is a message flow diagram of node initialization 
process according to an embodiment of the present inven- 
tion; 

FIG. 9D is a message flow diagram of node initialization 
process according to an embodiment of the present inven- 
tion; 

FIG. 10 is a message flow diagram of service management 
interface protocol according to an embodiment of the 
present invention; 
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FIG. 11 is a simplified block diagram showing Event 14 provides the communication methods for accessing tele- 
Manager uses according to an embodiment of the present com platform services layer 15, which is comprised of 
invention; telecommunications middleware services. Telecom platform 

FIG. 12 is a simplified information and problem report services layer 15 is the software layer that provides the most 

(IPR) flow diagram according to an embodiment of the 5 commonly needed middleware services for a UNIX-based 

present invention; telecommunications system, for example. System interface 

FIG. 13 is a simplified IPR processing flow diagram la y 6r \ 6 » comprised of operating system (OS) API and the 

according to an embodiment of the present invention; network links. System interface layer 16 defines the func- 

~ A . , T „„ , . , -j. tions of process and thread management, memory 

FIG. 14 is an exemplary IPR V1 ^ w graphical user interface 1Q m ment? timers> me tem> cornmunicat ion, interface 

according to an embodiment of the present invention; to ^ ^ components , Telecora 

FIG. 15 is a simplified block diagram showing data platform 10 allows higher level client applications 12 to be 

collection according to an embodiment of the present inven- decoupled from the operating system and network. By using 

tl0n ; telecom platform 10, developers may write applications 

FIG. 16 is a simplified block diagram of the data collec- 15 without having to master the intricacies of the underlying 

tion subsystem according to an embodiment of the present services, such as the operating system and the network, that 

invention; perform the work on behalf of the application. 

FIG. 17 is a simplified block diagram of the threshold FIG. 2 is a block diagram of the conceptual components 

counter data communication paths according to an embodi- associated with telecom platform 10. The smallest concep- 

ment of the present invention; 20 tual component is a configurable element (CE) 30. A con- 

FIG. 18 is a simplified block diagram of the threshold figurable element 30 is defined by telecom platform 10 as 

counter subsystem according to an embodiment of the one or more copies of a UNIX executable program that is 

present invention; administered by telecom platform 10. For example, a con- 

FIG. 19 is a simplified block diagram of the message finable element may be a link process, database, graphical 

handling subsystem according to an embodiment of the 25 ™* r interface, timing process .query process, error handlers, 

present invention* ctc * Configurable elements 30 are the fundamental building 

FIG. 20 is a sim'plined block diagram of message handling "octa of application programs The most basic services that 

4 j* . 1 j • 1 f +v, telecom platform 10 provides to application developers are 

testing according to an embodiment of the present invention; . r . f c rtr , » / 

mj r . . n L A . j those service to create, configure, and monitor configurable 

FIG. 21 is a simplified block diagram of the distributed 3Q clcmcn ^ 30 . Configurable elements 30 can be configured to 

object messaging environment according to an embodiment be starle(J a spedfic points dudng flode ^Kniion. The 

of the present invention; Unix executable configurable elements represent can be run 

FIG. 22 is a simplified block diagram of the internal multiple times for scalability or redundancy. Thresholds of 

debugging and tracing object relations according to an the number of instances of configurable elements required to 

embodiment of the present invention; 35 provide adequate services can be configured as well as 

FIG. 23 is a simplified block diagram of the dictionary whether or not the instances should be restarted automati- 

management system according to an embodiment of the cally by the telecom platform 10 in the event of a process 

present invention; failure. 

FIG. 24 is a simplified block diagram of the hardware Configurable attributes of a configurable element includes 

representation of the telecom platform according to an 40 RunLevel, which is the level a configurable element starts at. 

embodiment of the present invention; The RunLevels include PRE„MIN, OS_MIN, IN_SVC, 

FIG. 25 is a simplified block diagram of the software a ° d POST_IN_SVC. PRE_MIN run level specifies that 

representation of the telecom platform according to an ™e configurable element will be created automatically by a 

embodiment of the present invention; and service management subsystem at boot time. PRE_MIN 

FIG. 26 is a simplified block diagram showing dynamic 45 configurable elements are not monitored by the platform 

mapping of software onto hardware representation of the ma ° a S e ' subsystem OS_MIN specifies that the config- 

telecom platform according to an embodiment of the present ^^i?,^^^ 1110 °° 15 ^"fS 

invention to OS__MIN. IN__SVC specifies that the configurable ele- 
ment will be created when the node is transitioning to 

DETAILED DESCRIPTION OF THE 50 IN_SVC. POST_IN„SVC specifies that the configurable 

INVENTION element will be created when the node transitions to the 

Architecture Overview IN_SVC state. Another configurable attribute is 

Telecom platform (TP) 10 of the present invention is a NumberOflnstances, which specifies how many copies of 

software system designed to support the development and the executable is to be run. InServiceThreshold is a config- 

execution of distributed, scalable, fault resilient telecommu- 55 urable attribute that specifies how many out of NumberO- 

nications applications 12. Telecom platform 10 provides a flnstances is required to be up and running to make the 

unique set of tools developed for a computing environment configurable element's state be ENABLED. If the number of 

such as UNIX. These tools include not only the set of instances drop below this threshold, the entire configurable 

interfaces, libraries, and executables provided by the tele- element or all the instances of the configurable element are 

com platform development and runtime packages, but also 60 removed. Another attribute of the configurable element is 

a set of conceptual components necessary to design and the HeartbeatSchedule which specifies the schedule for 

manage distributed, scalable, fault resilient applications. heartbeat messages to be sent to a configurable element. 

As shown in FIG. 1, telecom platform 10 is comprised of Each configurable element also has an AuditSchedule, 

three distinct software layers 14-16. Layer #1 is a telecom which specifies the schedule for audit messages to be sent to 

platform application programming interface (API) layer 14; 65 the configurable element. 

layer #2 is a telecom platform services layer 15; and layer #3 A configurable element set (CESet) 26 is defined by 

is a systems interface layer 16, Telecom platform API layer telecom platform 10 as a group of configurable elements 
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designed to be deployed together on one or more nodes 24. 
A configurable element set is a distributable component. 
Telecom platform 10 may not manage configurable element 
sets 26 directly, but does support their creation and deploy- 
ment. Configurable element sets 26 can be viewed as being 
the distributable and/or replicable components of an appli- 
cation 28. 

An application 28 is defined as a group of configurable 
element sets 26 that fully define all of the configurable 
elements 30 of a distributed program. Telecom platform 10 
provides software to manage applications 28 within a site 
20. Defining the configuration of applications in terms of 
their distributable components allows the software for a 
distributed application to be defined independently of the 
hardware on which it will be run. An application's config- 
urable element sets will at some point in time be deployed 
to the nodes 24 of a site 20. When that occurs the scale and 
fault resilience of the application 28 will be determined 
based on the number of nodes used to support each config- 
urable element set. 

A node 24 is defined as an instance of a supported 
operating system on which telecom platform 10 runs. Tele- 
com platform 10 provides software that manages processes 
on nodes 24. Nodes 24 may be fault tolerant or non-fault 
tolerant, single or multi-processor. Telecom platform 10 uses 
the services of the operating system and is generally 
unaware of the hardware it is running on. Telecom platform 
requires very little configuration information for a node 24. 
Nodes are configured into the system by providing their 
name and unique device identifiers. 

Nodes 24 have operating states, supported by telecom 
platform, that describe the ordering of configurable elements 
started within them. The operating states includes HALTED, 
PRE„MIN, OS„, MINt & SVC, and POST_IN_SVC. The 
HALTED node state indicates that the operating system of 
the node has been shut down. The PRE_MIN state is used 
to start configurable elements that need to be started before 
configurable elements in the OS_MIN states are started. 
Telecom platform starts all configurable elements that are 
configured to run at PRE_MIN for that node first, then 
immediately begins running configurable elements that are 
configured to run in the OS_MIN state. Configurable ele- 
ments that are configured to run at PRE__MIN do not 
directly effect the state of the node. The OS _MI node state 
coordinates all configurable elements configured for the 
OS_MIN run level will be started to bring the node to the 
OS_MIN state. All configurable elements configured for the 
OS_MIN node state achieve their configurable run-level 
transition state before the node is said to have transitioned to 
OS__MIN. Once the OS_MIN node state has been achieved, 
if any configurable element changes its state to be below its 
run-level transition state, the telecom platform will down- 
grade the node to the HALTED node state. A shut down node 
may recover automatically. The IN_SRV node state coor- 
dinates configurable elements configured for the IN_SRV 
run-level. All configurable elements configured for the 
IN_SRV node state achieve their configurable run-level 
transition state before the node is to have transitioned to 
IN__SRV. Once the IN_SRV node state has been achieved, 
if any configurable element changes its state to be below its 
run-level transition state, the telecom platform will down- 
grade the node to the OS__MIN node state. Automatic 
recovery of a node may occur if the node downgrade was not 
originated manually. The POST_IN_SRV node state is 
used to configure configurable elements that are to be started 
immediately after a node has transitioned to IN_SRV. Once 
a node has achieved IN_JSRV, the telecom platform creates 
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each POST_JN_SRV configurable element. State changes 
for POST_IN_SRV configurable elements do not affect 
node state, and may be started and stopped repeatedly. The 
process of stopping a POST_IN_SRV configurable element 

5 does not cause the node to downgrade to a lower node state. 
A site 20 is defined by the telecom platform to be a group 
of nodes that distributed applications can be deployed 
across. Telecom platform provides a telecom platform appli- 
cation known as the platform manager that manages nodes 

10 24 within a site 20. A site may be made up of at least one 
node. In multi-node sites, the platform manager application 
may run as an active/standby distributed application in two 
of the nodes. In single node sites, the platform manager 
application runs in the single node along with user defined 

15 applications, but runs without the fault handling capabilities 
provided by a standby node. Administration of a site is 
provided through the platform manager. 

A processor service group (PSG) 22 is defined as a group 
of nodes that a specific configurable element set 26 is 

20 deployed to for redundancy. Telecom platform 10 provides 
software applications to manager processor service groups 
within an application. Processor service groups support 
redundancy by allowing the telecom platform user to iden- 
tify the number of nodes a configurable element set is 

25 required to run on to provide an adequate level of service. As 
the state of the nodes or the configurable element sets 
running on them change, telecom platform 10 verifies that 
the appropriate level of service is maintained or it will 
change the application status as configured. 

30 FIG. 3 is a diagram illustrating a system 40 design 
employing the conceptual components of telecom platform 
10 which are mapped onto hardware components. 

In terms of hardware configuration, a node is a computer 
processor within a network (such as ethernet) that can act 

35 either as a client or a server. Each node has a single instance 
of the operating system running on it. The processors within 
a node cannot run independently from one another because 
of their dependence on the operating system. Each node at 
a site can be classified as a platform manager or an appli- 

40 cation node. A site can consist of one node or a grouping of 
nodes that are connected to a host. The platform manager 
node has a redundant mate. The platform manager node and 
its mate may operate in an active/standby mode or a load- 
sharing mode. 

45 System 40 has eight nodes, which includes two platform 
manager nodes (active 42 and standby 43) and six applica- 
tion nodes 44-49. An application 50 for handling telephone 
calls based on the time the call is placed, or time dependent 
routing, is deployed across the nodes. Configurable element 

50 sets 52 and 54 of application 50 are the distributed compo- 
nents which supply the time dependent routing functionality. 
Each configurable element set 52 and 54 contain the soft- 
ware processes of the UNIX executable programs or con- 
figurable elements for a specific time zone. As shown, 

55 application 50 does not have to reside on a single application 
node 44-49. It may be desirable to map configurable ele- 
ment sets onto different nodes. This makes it possible to 
scale the application by increasing the number of nodes to 
which the configurable element sets are configured. 

60 The telecom platform internal architecture is described 
from both the logical and physical partitioning perspectives. 
The logical partitioning decomposes the telecom platform 
into distinct functional areas as shown in FIG. 4. Each 
functional area contains a cohesive group of classes, which 

65 together provide one particular system function. The physi- 
cal partitioning describes the concrete software and hard- 
ware decomposition of the system's context. The services 
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provided by telecom platform 10 may be partitioned into 
two groups: application services 60 and core services 62. 
Application services may include services that perform 
information and problem report (IPR)/alarm 64, statistics 65, 
dictionary 66, graphical user interface (GUI) 67, and host 
maintenance simulator (HMS), IPR/alarm services 64 pro- 
vide a standard mechanism to inform the system user of 
error conditions and other pertinent system information. 
Statistics services 65 provides the methods to access system- 
wide measurement data and to generate reports based on the 
collected data. Dictionary services 66 provide classes that 
are designed to support data storage (persistent, shared or 
private) and access to the data. Graphical user interface 
services 67 provide primitive abstractions for building GUI 
applications, and access to system utilities and to the system 
itself, e.g., xterm window and operating system utility 
programs. Host maintenance simulator services 75 provide 
a method of interfacing with the telecom platform when 
there is only one node within the system or when there is not 
a host to which to connect. It is through the host that control 
and operation of the platform is made possible. 

Core services 62 may include services that perform net- 
work management 68, node management 69, distributed 
object 70, communications 72, common functions 73, and 
event handling 74. Network management services 68 directs 
network activities, e.g., configuration of nodes and network- 
level fault processing. Node management services 69 directs 
node-level processes, e.g., node status reporting and link 
management. Distributed object services 70 provide a dis- 
tributed database repository for object-based communica- 
tion in a multi-processing environment. Communications 
services 72 provide the mechanism for handling messages 
across interprocessing links external to the platform. Com- 
mon services 73 provide a library of programming tools to 
aid in the rapid development of processes designed to run on 
or within the telecom platform. Event services 74 provide 
the capability to initiate, terminate, and/or distribute specific 
actions significant to a task. 

As a minimum, telecom platform provides all of the core 
services. High level applications use these services to 
accomplish the lower level functions. 

FIG. 5 further shows the telecom platform services and 
their dependencies. The developer accesses all of the core 
and application services through telecom platform applica- 
tion program interfaces 14. The developer may also access 
the operation system, network, and third party software/ 
hardware if the need arises. Interprocess object-based com- 
munication is handled by communication services 72. Most 
of the core and application services dependent on commu- 
nication services 72 and common services 73 to perform 
their respective functions. Graphical user interface services 
67 may only be dependent on communication services 72. 
The arrows in FIG. 5 indicate the dependency relationships 
between the services. 

FIG. 6 is a diagram of the physical partitioning of telecom 
platform 10 which includes an application layer 80 and a 
core layer 82. Core layer 82 containing core services 62 
exists for every instance of a telecom platform. Core layer 
82 contains telecom platform API 14, interprocess commu- 
nication mechanisms, event mechanisms, and platform man- 
agement. Telecom platform applications layer 80 has both 
vertical and horizontal partitions. Vertically, each telecom 
platform application process is classified as either a part of 
a main set of applications 84 or not. Non-main set processes 
are dependent on the main set processes. Horizontally, 
telecom platform applications 80 are categorized as required 
or optional. Optional applications may include an IPR/alarm 
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package 86, a data collection package 87, a dictionary 
management system package 88, and a host maintenance 
simulation package 89. 
The following is a more detailed description of Telecom 

5 platform services. 

Network Management Services 

Network Management services 68 provides a common 
administrative view of the network element. It is responsible 
for implementing high level operations on the network 

10 element nodes such as removing server nodes from service, 
restoring server nodes to service, removing applications 
from service, restoring applications from service, enabling 
or disabling applications, maintaining status of distributed 
applications, maintaining server node state and status, and 

15 reporting application status changes. Network management 
services 68 includes a network platform manager (NetPM), 
network system integrity subsystem (NetSI), and configu- 
ration manager (ConfigMgr). FIG. 7A is a block diagram 
showing an active platform manager node 100 with a 

2Q corresponding or mated standby platform manager node 
102. Each platform manager node includes a network plat- 
form manager 104, a network system integrity subsystem 
106, and a configuration manager 108. A platform manager 
network test driver 110 provides network level testing. 

25 Network Platform Manager (NetPMMain) 

The class name for the network platform manager is 
NetPM. NetPM is responsible for providing management 
functionality of the platform resources. The platform is a 
distributed system consisting of multiple nodes or servers 

30 which provide processing power for specific services, such 
as calling card or credit card validation. The service pro- 
vided by a server is determined by the configurable elements 
residing on the node. NetPM manages all the configuration 
data associated with the platform. Configuration data 

35 includes information about the hardware, such as the TCP/IP 
address of a server, status information, such as server and 
query status, software configuration information, such as 
application type, node name, and information relating to the 
individual configurable elements. 

^ NetPM maintains the following configuration informa- 
tion. This information is collected by NetPM during its 
initialization. 

Configurable element descriptor information — This pro- 
vides configuration information for each Configurable 

45 element of the platform. NetPM retrieves these from a 
disk file containing the information on configurable 
elements of different types. 
Application information — This provides configuration 
information about each application (service), which can 

50 be used in calculating an application's status. NetPM 
retrieves this information from a disk file containing the 
information for all the applications in the platform. 
Processor service group information — This provides con- 
figuration information about Processor service groups, 

55 which can be used in calculating the Processor service 
group status (Processor service group designates group 
of processors serving the same application, i.e., CCD, 
CCL). NetPM retrieves these from a disk file contain- 
ing the information for all Processor service groups in 

eo the platform. 

Server information — This provides specific information 
about all servers in the platform. NetPM requests and 
retrieves this information from the ConfigMgr. Config- 
Mgr provides NetPM with the server information on 

65 platform manager nodes first. Afterwards if ConfigMgr 
determines that the current server is the active platform 
manager, it provides the local NetPM with the infor- 
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mation on the remaining servers in the platform. Oth- status from NodePM, the application status is calculated and 

erwise (standby platform manager), NetPM will the registered function is called with the old and new 

retrieve those information from its mate, and not from application statuses. Application status can also be solicited, 

the ConfigMgr. during which NetPM will return the latest calculated value 

If an error is detected while collecting these information, 5 of application status saved in its NetMAP to the requesting 

NetPM issues appropriate IPRs and exits. process. 

NetPM uses a NetMAP object to manage all the configu- NetPM provides, partially through the use of two alias 

ration data. NetPM also uses a persistent dictionary to retain objects, two sets of routing options to other processes 

server status, query status, and scheduled actions informa- wishing to communicate with NetPM. NetPM provides a 

tion across platform manager resets. A Disk File Dictionary to local, and a global active-standby option. In the local option, 

object is used to manager this dictionary. NetPM is respon- all NetPM client requests are sent to the NetPM server object 

sible for maintaining the integrity of the configuration data in the same node as the client object. In the global active - 

between the two platform manager servers. NetPM uses a standby option, all NetPM client requests are sent to the 

persistent dictionary, database equalization, and auditing to globally (i.e. possibly inter-nodal) available active NetPM 

maintain the integrity of the data. 15 server object. 

Application status is determined based on the processor NetPM provides a set of reader, and writer, functions for 

service group status. The following criteria is used in a lot of the Server configuration data. These include reader/ 

determination of the processor service group status: writers for the schedule action data, the platform manager 

PSG_DISABLED — At least a set number of servers in active status data, the server status data, etc. NetPM provides 

the processor service group are in disabled state. 20 no direct read/write operations for the configurable element 

PSG__INACnVE— At least one server in each processor description data, 

service group is in standby state, and none is in active NetPM ^ provides a function to initialize the majority 

state of the Server configuration data. This function expects a 

PSG_ACnVE_MINIMAL~Only certain number of ServerfcfoMsg object as ixiput. . 

servers in the processor service group are in active 25 NetPM provides a set of functions which cause a specific 

state configuration action (such as graceful halt, immediate halt, 

^ „ . ^™ TrT . . , c . . graceful downgrade, and restore), to occur on a specific 

PSG_ACTIVE— A set number of servers in the processor | erver 

service group are in active state (Note: This number XT * , . 4 . ... * *. u 

■ii u * *u .u u * .u * a * NetPM provides a function where the server status can be 

will be greater than the number of servers that need to 3Q ch d 0 £ a dfic ^tr 

be active for PSG_^CT1VE MINIMAL.) NetPM provides a function to enable, and a function to 

and application status may be derived using the follow- dM processing QQ a ^ 

m ^ ^ Jll" t, t ~ * ■ it- NetPM provides several functions which "report" server 

AP_DISABLED— At least a set number of processor status? and status changes. These routines save the 

P^nSpn g,WD appllCatl0n haVC StatUS ° f 35 new status information in NetMAP, notify the ConfigMgr 

PSG_DISABLED. software of the change, and broadcast the change to all the 

AP_JNACnVE— At least one processor service group NodePM software in the platform. 

for the given application has status of PSG_ NetPM is also responsible for time synchronization within 

INACTIVE, and no processor service group has status me aetwor k. Time synchronization consists of three 

of PSG_ACTIVE. 40 major parts, as shown in FIG. 7B. The first part is for active 

AP_ACTI VE_MINIMAL— A set number of processor platform manager 100 to equalize its local time with the time 

service groups for the given application have status of G f the host. This includes converting the host's (110) time 

PSG__ACTIVE_MINIMAL or higher (PSG__ mto a usable form and informing the NodePMs 112 on 

ACTIVE). platform manager nodes 100 and 102 to perform an 

AP__ACTI VE_PARTIAL — A set number of processor 45 adj time( ) function to adjust their clocks in line with host 

service groups for the given application have status of 110. NetPM 104 also informs the host ticker class of the new 

PSG_ACTIVE_MINIMAL or higher (PSG_ host time when it receives the time message. An xntp 

ACTIVE) (NOTE: The number of processor service process 120 then synchronizes the application nodes* (121) 

groups required for AP_ ACTI VE_PARTTAL state is time with the time of the platform manager nodes 100 and 

greater than required number of processor service 50 102. Each of the platform manager nodes 100 and 102 are 

groups for AP_ACTIVE_MIN1MAL). configured as xntp master sources of time. The xntp daemon 

AP_ACTIVE — A set number of processor service groups slaves 122 on application nodes 121 choose one of the 

for the given application have status of PSG_ J ACTIVE master xntp daemons 120 on platform manager nodes 100 

(NOTE: The number of processor service groups and 102 to keep in synch with. Finally, whenever an unso- 

required for AP ^ACTIVE stat is greater than required 55 licited Set Time message is received from host 110, the 

number of processor service groups for network's time is the same as the received time. 

AP_ACnVE__PARTIAL). Lastly, NetPM 104 provides a function which provides a 

NetPM keeps track of the status changes on each server newly booted node with pertinent server configuration data 

node, and as it gets them it determines the status of the of all the servers in the platform. NetPM 104 is a config- 

processor service group and in case of a change, determines 60 urable element. NetPM 104 provides the unencapsulated 

the new application status for the node, and informs Con- operations: Remove, Restore, and GetStatus which NodePM 

figMgr of these changes. requires to control NetPM's execution. NetPMTimerHan- 

NetPM provides solicited and autonomous updates on dler is called when the audit timer fires. It aborts the provide 

application status. For autonomous updates, the application service loop and calls the NetPM function SettimeTo Verify 

process first registers a function with NetPM to receive 65 to start the audit, 

updates for a particular application type (CCD or CCL). NetPM 104 is an object with its own thread of control. 

Whenever NetPM receives a change of server or query After building up its NetMAP lists, NetPM 104 goes into an 
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infinite loop waiting for requests. NetPM 104 notifies Con- NetSI routinely audits the status conditions of both PMs. 

figMgr 108 whenever there is a change in the service or If invalid conditions are present, NetSI attempts to correct 

query status of a server. NetPM 104 also sends these status the situation by setting the active status to the correct state, 

changes to all the NodePMs 112 in the platform. NetPM 104 other processes can also request NetSI to audit the platform 

notifies the specific NodePM 112 to enable, or disable, query 5 manager status conditions. 

processing. NetPM 104 provides service status synchroni- NetSI ^th a "send to both" load shared concept, 

zation functionality. NetPM 104 builds up the IPU informa- If ^ platform manager nodcs are operational, each NetSI 

tion for the servers in the platform and passes this informa- prooess on each platform man ager node will receive the 

tion to the specific NodePM 112 in the BootNotify member NodeSI request Each NelSI process ^ determine if it 

function. NetPM, m all the configuration requests for deg- 10 should har)dIe me request based on the platform's active/ 

radation of service (i.e. GraceDowo, ImmedDown, standby state and fauked ^ ^ active platform man . 

GraceHalt, and ImmedHalt), notifies the specific NodePM ager > s NetSI process ^ U suaUy take the required action 

112 of the desired state of the server. NetPM 104 does wMle me standby platform manager discards the informa- 

several things when a server restore is requested. First, tion However, if the faulted node is the active platform 

NetPM 104 obtains the current status of the server from the 15 managcr> me standby platform manager (if va i id ) will set 

specific NodePM 112. Second, if the returned status is itsdf to active and takc thc request actioQ to downgrade the 

out-of-service/minimum-software, NetPM 104 sends the other p i at f orm man ager node. 

specific NodePM 112 the relevant NodeSpecInfo. Third, Each time a NetSI operation is called, NetSI first deter- 

NetPM 104 sends the relevant configurable element descrip- mines if it ^ the active or stan dby platform manager. If 

tor information to the specific NodePM 112. Lastly, NetPM 20 active? NetSI will process the request for all conditions 

tells the specific NodePM to restore to service. except wheQ me target Qode ^ itself and ^ mate h m 

Network System Integrity (NetSIMam) service jf m stand b y , NetS1 ^ discard the request for ^ 

The Network System Integrity (NetSI) subsystem 106 conditions expect when the target node is the mate, 

provides monitoring and recovery operations for the net- During initialization NetSI requests the mate's node name 

work element. It is responsible for implementing network 25 andserve r descriptors of its own server and mate server from 

monitoring and recovery. Operations implemented by Net- Node p M . Before requesting the information, NetSI polls for 

work System Integrity include: ^ stams of NodePM) aad ^ not requcst me nodc name 

platform manager active/standby status monitoring and server descriptors until NodePM is read to provide them. 

node failure report correlation NetSI will not be ready to provide service until this infor- 

failed node recovery actions 30 mation is received properly. 

The class name of Network System Integrity is NetSI. NetSI NetSI uses the command line parameter DWN_RPT_ 

106 manages network system integrity for the platform FILE to get the name of the network configuration 

manager. NetSI 106 receives notifications of server down- (downgrade) report file name. If this parameter is not 

grades and communication faults from the NodeSI on the specified, no report entry is made of the downgrades, 

faulted node. NetSI 106 determines what action should be 35 Referring to FIGS. 7C and 7D, process interaction 

taken based on the data given by NodeSI. If the node between node management and network management is 

indicates a downgrade, NetSI will take the appropriate shown. Constant monitor (ConMon) 132 is an instance of an 

action to downgrade the node from the network level to the object running on an application node 136. ConMon 132 

desired downgraded state. If the node indicates a commu- detects a faulted process or a failed configurable element, it 

nication fault, NetSI 106 will determine what node (if any) 40 notifies a service management process program 134. Service 

is at fault from data received previously and will take action management process 134 determines if the configurable 

to downgrade the faulted node if necessary. When NetSI element failure causes the process to fall below its threshold 

determines that a downgrade is required for a node, NetSI level. If it does not, the service management process 134 

calls the appropriate NetPM operation to perform the down- restarts the configurable element. However, if the config- 

grade. If a change in active status is required, NetSI calls the 45 urable element does fall below its threshold level then 

appropriate NetPM operation to set the active status. After service management process 134 generates a configurable 

NetPM is called to perform the downgrade, NetSI notifies element status change message and forwards the notification 

ConfigMgr that the status is changing for a particular node. to NodeSI 130. NodeSI forwards the configurable element 

This allows the host to be informed immediately that a node status change to NodePM 112. NodePM 112 determines 

is being downgraded. NetSI then writes an entry to the 50 whether the configurable status change affects the run level 

network configuration report indicating the status change of the node, which could cause a downgrade of the node. If 

and reason for it. NetSI downgrades nodes to the legal the node is to be removed, NodePM 112 provides instruc- 

service state based on the current state of the node. tions to service management process 134 to remove all of the 

NetSI contains a communication fault list This list holds configurable elements necessary to achieve the downgraded 

the reporting server node name and problem server node 55 state. NodePM 134 notified the NetPM 104 of the node 

name of each communication fault report received. When a status change. NetPM 104 performs a calculation to deter- 

comtnunication fault report is received, the list is searched mine if the node status change affects the processor service 

for another report about the problem node. If not found, the group and application status. NetPM's calculation also 

fault information is added to the list. NetSI also contains a determines if an auto-action, such as removing a node from 

down status info list. When NodePM indicates that a node is 60 in-service to min-set and restoring it again, should be 

out of service and the NetPM status does not indicate the performed on the node. If the node is to be removed, then the 

node is halted, a down status info entry is created with the node status change is forwarded from NetPM to ConfigMgr 

node name of the halted IPU. A timer is created and the 108. ConfigMgr notifies host 140 of the state change for the 

down status info is added to the list. If NodePM later node, processor service group, and application. These state 

indicates a higher status for that node (before the timer 65 changes can be displayed or printed in a report, 

expires), the down status info entry is cleared from the list In particular, each NetSI determines if it should handle the 

and no further action is taken. downgrade request. If so, the target server's status is 
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retrieved. If the target server is not already halted, the server APPL_JSTATUS_MSG 

is downgraded to the appropriate status based on the IPU ASPEC_MSG 

status. If the IPU status is out of service, NetSI calls CONFIGURE_SERVER_MSG 

NetPM's immediate halt operation to either auto halt or PSG_INFO_, MSC 

manually halt the target node. If the IPU status is Out of 5 PSG_STATUS__MSG 

service minimal (OS-MEN), NetSI calls NetPM's immediate QUERY PROCESSING MSG 

downgrade operation to downgrade the target node to RESET SERVER_MSG _ 

OS-MIN. If the IPU status is in service disabled, NetSI calls ~ 
NetPM's disable query operation to disable query status for 

the target node. In all cases, NetsSI updates the active status 10 

if the target node is the active platform manager. Also, if the SERVER_INFO_MSG 

target node is part of the local site, NetSI informs the host SERVER_STATUS_MSG 

via ConfigMgr that a status change is occurring and initiates TEST_SERVER^MSG 

recovery of the processor service group (through TIME_MSG 

ConfigMgr) if it determines that the processor service group 15 ConfigMgr also provides operations to the platform man- 

of the target server should be recovered. NetSI then writes ager for retrieving server and time information from the 

an entry to the network configuration report file indicating host. It also provides operations to notify the host of server 

the status change is occurring due to the node reporting a status changes. In processing host command messages, there 

fault . are times when ConfigMgr must wait for a response from the 

NodeSI informs NetSI of communication faults that occur 20 host or for a status change from a particular server. Config- 

between two nodes. NetSI stores or takes action on the fault Mgr uses a non-blocking philosophy in respect to these 

based on previous information receive (if any). Each NetSI waits. Instead of stopping and waiting for the event to occur, 

determines the status of the reporting and problem nodes. If ConfigMgr saves the desired response or status on a Pend- 

either server is halted, the communication fault report is ingQueue and continues normal processing of another Host 

discarded since the integrity of the data cannot be assured. 25 message or providing service to a client When the desired 

If neither server is halted, the Communication Fault List is response or status occurs, the appropriate procedure is called 

searched for another report on the problem node. If no report to resume processing of the host commanded message. If the 

on the problem node is found, a Communication Fault List desired response does not arrive or desired status does not 

entry is added to the List with the server information. If occur within the specified time limit, a fail procedure is 

another report of the problem node is found and another 30 called to clean up processing of the Host commanded 

reporting server has reported it, the problem server is set up message and issue IPRs as needed, 

for downgrade processing. Once a decision is made about In addition to processing host command messages, Con- 

whether the server should be downgraded, NetSI determines figMgr is required to notify the host when a status change 

if it should handle it (based on its active state and whether occurs. When ConfigMgr is notified of a status change, it 

or not the target server is itself.) If it should handle the 35 checks the status pending queues to determine if it is waiting 

downgrade, NetSI calls NetPM's Immediate Halt operation for the status change to occur. If so, the pending queue 

to either Auto Halt or Manually Halt the problem node. If the success operation is performed. Otherwise, ConfigMgr 

server to be halted is the active PM, NetSI updates the active sends server status messages to the host. In processing host 

status accordingly before halting the node. Also, if the target response messages, ConfigMgr checks the host response 

is part of the local site, NetSI informs the Host via Config- 40 pending queue (HostPendQueue) to determine if it is waiting 

Mgr that a status change is occurring and initiates recovery for the response. If so, the pending queue success operation 

of the Processor service group (through ConfigMgr) if it is performed. Otherwise, ConfigMgr discards the response 

determines that the Processor service group of the target message from the Host When a platform manager node is 

server should be recovered. NetSI also writes an entry to the booted to OS-MIN state, it audits its mate and determines 

network configuration report file indicating the halt is occur- 45 the status of the mate. In the event that no mate platform 

ring due to a communication fault. manager node is present, the mate status is automatically set 

Configuration Manager (ConfigMgr) to halted. Similar audits are done on service server nodes 

The Configuration management subsystem (class name: (nodes other than PM) to determine their status. 
ConfigMgr) provides the control interface between the SCP ConfigMgr has a registration capability where a sub- 
Host and Server components. All operations that can be 50 system can register to provide routing information for a 
performed on the server network are defined in this inter- particular application. When the Host requests routing inter- 
face. The Configuration Management subsystem imple- mation about an application, ConfigMgr makes a request to 
ments the following features: the appropriate registered subsystem (if one exists) to pro- 
Control Message Interface between Host and Servers vio^ the routing info 

w 55 Configure Server Messages (ConfigServerMsgs) require 

State Machine for valid operations spedal processing due to the naturc of the servte ^ m 

Drives Network Management with requests. performed (i.e. halts, downgrades, restores, and boots). 
Controls operation timing/timeouts. Since host messages are sent to both platform manager 
ConfigMgr manages server configuration control for the servers, care must be taken to assure that only one platform 
platform manager. ConfigMgr receives Host messages trans- 60 manager node processes the request This requires checking 
mitted on the CONFIGCTL, MAINT, APPLCTL and the server state of the platform manager node and its mate. 
ROUTINGCTL logical links and processes each based on its There are different actions to be taken based on the server 
message id and type. If the Host requires a response or report stats of the platform manager nodes and whether the Con- 
to be sent, ConfigMgr determines the necessary response figServer request is for a platform manager node, its mate, 
and retrieves the necessary report information and sends it 65 or a service server. Two finite state machines 
back to the Host. ConfigMgr handles the following mes- (PMCfgSvrFSM and SvcCfgSvrFSM) manage all the dif- 
sages: ferent state driven actions. 
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PMCfgSvrFSM is the finite state machine that handles the node that is active will send a DENY-AMP not In-Service 
restores, halts, resyncs, downgrades, and boots for a plat- response back to the host. If a halt, downgrade, or boot 
form manager application server. This machine processes a request is not denied, the host considers the action success- 
request based on whether the request is for itself or its mate, fill. 

its own status, its mate's status, and the event requested 5 A force Sag is checked when a halt, downgrade, or boot 
(halt, downgrade, restore, etc.) The platform manager server is requested for the last In-Service node of an application. If 
states checked are: Halted (Auto), Halted (Manual), XOS- the force flag is not set, the request will be denied with a 
MIN, AOS-MIN (Auto), MOS-MIN (Manual), and In-Svc. response of "DENIED-LAST SERVER IN Processor ser- 
if In-Svc, the active/standby status is checked to determine vice group PROCESSING QUERIES". If the force flag is 
if the server is active or standby. Valid events are Restore, 10 set, the halt, downgrade, or boot will be performed on the 
Graceful Halt, Immediate Halt, Graceful Downgrade, Imme- last In-Service node of the application, 
diate Downgrade, Graceful Boot, Immediate Boot, and Host An Under Configuration flag is checked whenever a 
Resync. configure event (except Immediate Halts) is processed. If the 
The event is important for determining which platform Under Configuration flag is set, the request will be denied 
manager node will process the request. If a restore is 15 with a response of "DENI ED-SERVER UNDER CON- 
requested, normally the platform manager node which is FIGURATION". ConfigMgr sets and clears the Under Con- 
being restored will process the restoration (i.e. a platform figuration flag during event processing. The other messages 
manager node will restore itself). Processing a restore (i.e. ServerlnfoMsg, ServerStatusMsg, TimeMsg, etc.) do 
request a platform manager server that is halted, the halted not require finite state machines. 

server's mate (if able) will send a Denial response back to 20 When a restore request is not denied, ConfigMgr sets the 
the host. If any Halt, downgrade, or boot is requested for a UnderConfig flag for the server, sends a ConfigServerMsg 
platform manager node, the platform manager node's mate "Action Initiated" RESPONSE to the Host, and calls Restor- 
will process it, unless the mate is halted. When the mate is elSV operation of NetPM to restore the server to In-Service, 
halted the platform manager node will process the halt, ConfigMgr then suspends restore processing and sets up a 
downgrade, or boot for itself. Processing a halt, downgrade, 25 Server Status PendingQueue entry for the server to become 
or boot may involve actually performing the requested In-Service. Restore processing will not cootinue until Con- 
action or sending a Denial response back to the host. If a figMgr is informed that the server status is In-Service or the 
halt, downgrade, or boot request is not denied, the host timer expires. When ConfigMgr is informed of the server 
considers the action successful. status change to In-Service, Restore processing is continued 

When a platform manager node has to process a boot for 30 by checking the server query status. If the server's query 

itself, the platform manager node calls the GraceHalt or status is DISABLED_SERVER_OOS and the number of 

ImmedHalt operations (based on Boot type) of NetPM to active servers is less than the processor service group active 

bring itself into a halted state. Processing is then complete server count, ConfigMgr calls EnableQuery operation of 

for this node since it is being brought down to a halted state. NetPM to enable the server's query status and sets the 

(The host will initiate the reset and boot of the server.) A 35 current query status to Pending. ConfigMgr then sends 

force flag is checked when a halt, downgrade, or boot is server status messages to the host informing about server 

requested for the last In-Service platform manager node. If and query status change. A QueryStatus PendigQueue entry 

the force flag is not set, the request will be denied with a is set up for the server's query status to become Enabled, 

response of "DENIED-LAST AMP". If the force flag is set, Processing is then suspended until the query status becomes 

the halt, downgrade, or boot will be performed on the last 40 enabled or the timer expires. When ConfigMgr is informed 

In-Service platform manager node. of the query status change to Enabled, Restore processing is 

If a Host Resync is requested for a platform manager continued with the sending of server status messages and 

node, the target platform manager server's mate will process clearing of the under configuration flag for the server, 

the request unless the mate is halted. If the target platform Restore fail processing is initiated if the timer expires 

manager server's mate is halted, the platform manager node 45 before the server status changes to In-Service or the 

for resync will process the request. Processing the request requested server information for the other applications is 

involves changing the server status from XOS-MIN to never received. Fail processing involves gracefully down- 

AOS-MIN or MOS-MIN or denying the request if the grading the server to OS-MIN, issuing an IPR, and clearing 

current status is not XOS-MIN. the under configuration flag for the server. If the timer 

SvcCfgSvrFSM is the finite state machine that handles the 50 expires before the query status changes to Enabled, Restore 

restores, halts, resyncs, downgrades, and boots for a Service processing is continued with setting the Query Status to 

application server. This machine processes a request based Disabled, gracefully downgrading the server to OS-MIN, 

on the state of the platform manager node performing the sending server status messages, issuing an IPR, and clearing 

action, the state of the service server being worked on, and the under configuration flag for the server, 

the event requested (halt, downgrade, restore, etc.) The 55 When a Graceful Halt request is not denied, ConfigMgr 

service states checked are Halted (auto), Halted (manual), sets the UnderConfig flag for the server, sends a Config- 

XOS-MIN, AOS-MIN (auto), MOS-MIN (manual), and ServerMsg "Action Initiated" RESPONSE to the Host, and 

InSvc. Valid events are Restore, Graceful Halt, Immediate calls GraceHalt operation of NetPM to halt the server. If the 

Halt, Graceful Downgrade, Immediate Downgrade, Grace- node is not already halted, ConfigMgr then suspends halt 

ful Boot, Immediate Boot, and Host Resync. 60 processing and sets up a Server Status Pending Queue entry 

The active platform manager node (OS-MIN or for the server to become Halted. It then makes an entry to 

In-Service) will process the configure server request for a network configuration report indicating a halt was requested 

Service server. A boot, halt, resync, or downgrade is allowed by the host, halt processing will not continue until the 

on a service server as long as one platform manager is at ConfigMgr is informed that the server status is Halted or the 

least OS-Min. A restore for a service server is only allowed 65 timer expires. When ConfigMgr is informed of the server 

when at least one platform manager is In-Service. If neither status change to a halted state, halt processing is continued 

platform manager node is In-Service, the platform manager with the sending of server status messages and clearing of 
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the under configuration flag for the server. If the timer 
expires before the server status changes to Halted, Halt fail 
processing is initiated. Fail processing involves issuing an 
IPR and clearing the under configuration flag for the server. 

When an Immediate Halt request is not denied, Config- 
Mgr sets the UnderConfig flag for the server, removes all 
pending server status changes for this server from the status 
pending queue, and calls ImmedHalt operation of NetPM to 
halt the server. If the node is not already halted, ConfigMgr 
suspends halt processing and sets up a Server Status 
Pending-Queue entry for the server to become Halted. It 
then makes an entry to the network configuration report 
indicating a halt was requested by the Host. Halt processing 
will not continue until the ConfigMgr is informed that the 
server status is Halted or the timer expires. When ConfigMgr 
is informed of the server status change to a halted state (or 
the node is already halted when the halt was issued), halt 
processing is continued with the sending of server status 
messages, sending of a ConfigServerMsg "Successfully 
Completed" RESPONSE to the Host, and clearing of the 
under configuration flag for the server. If the timer expires 
before the server status changes to Halted, Halt fail process- 
ing is initiated. Fail processing involves issuing an IPR, 
sending a ConfigServerMsg "Action Failed" RESPONSE to 
the Host, and clearing the under configuration flag for the 
server. 

When a Graceful Downgrade request is not denied, Con- 
figMgr sets the UnderConfig flag for the server, sends a 
ConfigServerMsg "Action Initiated" RESPONSE to the 
Host, and calls GraceDown operation of NetPM to down- 
grade the server. If the node is not already at the desired 
downgraded state, ConfigMgr then suspends downgrade 
processing and sets up a Server Status PendingQueue entry 
for the server to become OS-MIN. It then makes an entry to 
network configuration report indicating a downgrade was 
requested by the Host. Downgrade processing will not 
continue until ConfigMgr is informed that the server status 
is OS-MIN or the timer expires. When ConfigMgr is 
informed of the server status change to a OS-MIN state (or 
the node was already at that state), downgrade processing is 
continued with the sending of server status messages and 
clearing of the under configuration flag for the server. If the 
timer expires before the server status changes to a OS-Min 
state, downgrade fail processing is initiated. Fail processing 
involves issuing an IPR and clearing the under configuration 
flag for the server. 

When an Immediate Downgrade request is not denied, 
ConfigMgr sets the UnderConfig flag for the server and calls 
ImmedDown operation of NetPM to downgrade the server. 
If the node is not already at the desired downgraded state, 
ConfigMgr then suspends downgrade processing and sets up 
a Server Status Pending Queue entry for the server to 
become OS-MIN. It then makes an entry to network con- 
figuration report indicating a downgrade was requested by 
the Host. Downgrade processing will not continue until 
ConfigMgr is informed that the server status is OS-MIN or 
the timer expires. When ConfigMgr is informed of the server 
status change to a to OS-MIN state (or the node was already 
at that state), downgrade processing is continued with the 
sending of server status messages, sending of a ConfigServ- 
erMsg "Successfully Completed" RESPONSE to the Host, 
and clearing of the under configuration Flag for the server. 

If the timer expires before the status changes to a OS-MIN 
state, downgrade fail processing is initiated. Failure process- 
ing involves issuing an IPR, sending a ConfigServerMsg 
"Action Failed" Response to the Host, and clearing the 
under configuration flag for the server. 
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When a Graceful or Immediate Boot request is not denied, 
ConfigMgr sets the UnderConfig flag for the server and 
sends a ConfigServerMsg "Action Initiated" RESPONSE to 
the Host. ConfigMgr checks the server status for the server 

5 and calls GraceHalt or ImmedHalt operation of NetPM if the 
server is not at a halted state. If a halt operation is called, 
processing is suspended until ConfigMgr is informed that 
the server status is halted or the timer expires. It then makes 
an entry to network configuration report indicating a boot 

1Q was requested by the Host. 

When ConfigMgr is informed of the server status change 
to a OS_MIN state (or the node was already at that state), 
downgrade processing is continued with the sending of 
server status messages, sending of a ConfigServerMsg "Suc- 
cessfully Completed" RESPONSE to the Host, and clearing 

15 of the under configuration flag for the server. If the timer 
expires before the server status changes to a OS-MIN state, 
downgrade fail processing is initiated. Fail processing 
involves issuing an IPR, sending a ConfigServerMsg 
"Action Failed" RESPONSE to the Host, and clearing the 

20 under configuration flag for the server. 

When a Graceful or Immediate Boot request is not denied, 
ConfigMgr sets the UnderConfig flag for the server and 
sends a ConfigServerMsg "Action Initiated" RESPONSE to 
the Host. ConfigMgr checks the server status for the server 

25 and calls GraceHalt or ImmedHalt operation of NetPM if the 
server is not at a halted state. If a halt operation is called, 
processing is suspended until ConfigMgr is informed that 
the server status is halted or the timer expires. It then makes 
an entry to network configuration report indicating a boot 

30 was requested by the host. 

When ConfigMgr has determined that the server is halted, 
it sends a ResetServerMsg REQUEST to the Host. Config- 
Mgr creates a Host Response PendingQueue entry to await 
the ResetServerMsg RESPONSE from the host. Processing 

35 is then suspended until the RESPONSE is received or the 
timer expires. Once the RESPONSE is received, ConfigMgr 
sets up a ServerStatus Pending Queue entry to await the 
server status becoming OS-MIN. If the RESPONSE from 
the Host is not received before the timer expires, an IPR is 

40 issued and the under configuration flag is cleared. Once the 
Server Status becomes OS-MIN, ConfigMgr sends Server 
status messages to the Host indicating the new server status 
and clears the under configuration flag. If the timer expires 
before the server status becomes OS-MIN, ConfigMgr 

45 issues an IPR and clears the under configuration flag. 

When a Host Resync request is not denied, ConfigMgr 
determines if the server status is XOX__MIN. If so, Set- 
ServerStatus operation of NetPM is called to set the server 
status to the appropriate Auto/Manual OS__MIN state, 

50 server status messages are sent to indicate the new server 
status, and a ConfigServerMsg "Successful" RESPONSE is 
sent to the Host. If the server status is not XOS_MIN, an 
IPR is issued and a ConfigServerMsg "Action Failed" 
RESPONSE is sent to the Host. 

55 The Application Status Message is processed by the 
platform manager node that is In-Service Active. If neither 
platform manager node is In-Service, the platform manager 
node that is OS-MIN Active will process the request. Upon 
receiving an ApplStatusMsg REQUEST type messages from 

60 the Host, ConfigMgr determines the application query status 
and sends a ApplStatusMsg S_REPORT back to the Host 
with the current application query status. ConfigMgr sends 
ApplStatusMsg UNREPORT type messages to the Host 
when server status changes occur or as required during 

65 processing of a Host configure server request. 

ConfigMgr receives an ASPEC Data REQUEST message 
from the Host for each Application in the Applslnfo.des 
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descriptor file. ConfigMgr queries NetPM to retrieve the 
information for that application from the NetMAP. A 
response message containing the ASPEC Data is sent back 
to the Host, along with a response code indicating success or 
failure. IPRs will be issued if there is an invalid Application 5 
Id, a message other than the ASPEC Data REQUEST 
message, or a message type other than request. 

The Processor service group Info Message is processed by 
the platform manager node that is In-Service Active. If 
neither platform manager node is In-Service, the platform 10 
manager node that is OS-MIN Active will process the 
request. Upon receiving a PSGInfoMsg REQUEST type 
messages from the Host, ConfigMgr determines the Proces- 
sor service group Info and sends a PSGInfoMsg 
S__REPORT back to the Host with the Processor service 15 
group information. 

The Processor service group Status Message is processed 
by the platform manager node that is In-Service Active. If 
neither platform manager node is In-Service, the platform 
manager node that is OS-MIN Active will process the 20 
request. Upon receiving PSGStatusMsg REQUEST type 
messages from the Host, ConfigMgr determines the Proces- 
sor service group query status and sends a PSGStatusMsg 
S_REPORT back to the Host with the current Processor 
service group query status. ConfigMgr sends PSGStatusMsg 25 
UNREPORT type messages to the Host when server status 
changes occur or as required during processing of a Host 
configure server request. 

The Query Process Message is processed by the platform 
manager node that is In-Service Active. If neither platform 30 
manager node is In-Service, the platform manager node that 
is OS-MIN Active will process the request. ConfigMgr 
receives QueryProcMsg DISABLE_SERVER, DISABLE^. 
SERVERJORCED, and ENABLE_SERVER request 
types from the Host Upon processing this message, Con- 35 
figMgr initiates the enabling/disabling of query processing 
for the target server by calling the EnableServer/ 
DisableServer operation from NetPM. ConfigMgr will set 
up a QueryStatus PendingQueue entry for the server and 
suspend further processing until the query status for the 40 
server changes to the desired state or the timer expires. 
NetPM informs ConfigMgr of a change in query status by 
calling the NtfyQryStatChange operation of ConfigMgr. 
When ConfigMgr processes this operation, it will check the 
QueryStatus Pending Queue entries for the server query 45 
status state. If there is an entry with the desired query status, 
the appropriate success query processing procedure is called 
to resume processing of the QueryProcMsg. Success pro- 
cessing for the QueryProcMsg involves sending a Que- 
ryProcMsg RESPONSE back to the Host indicating the 50 
request was successful and changing the active status if 
necessary for a platform manager node. 

If the timer expires before the server query status is in the 
desired state, the appropriate fail query processing proce- 
dure is called to resume processing of the QueryProcMsg. 55 
Fail processing for the QueryProcMsg involves issuing an 
IPR and sending a QueryProcMsg RESPONSE back to the 
Host indicating the request failed. 

The ConfigMgr sends ResetServerMsg REQUEST type 
messages during boot processing of a server. When the Host 60 
requests a boot for a non-PM server, the ResetServerMsg 
REQUEST is sent after the target server has been halted. 
ConfigMgr then suspends boot processing and sets up a Host 
Response Pending Queue entry for a ResetServerMsg 
RESPONSE type message. Boot processing will not con- 65 
tinue until the RESPONSE is received or the timer expires. 
When ConfigMgr receives the ResetServerMsg RESPONSE 
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type message from the Host, ConfigMgr will check if there 
is an entry for the ResetServerMsg RESPONSE in the Host 
Response Pending Queue entry for a RestServerMsg 
RESPONSE in the Host Response Pending Queue. If so, the 
appropriate procedure will be called to complete boot pro- 
cessing. 

The Routing Info Message is processed by the platform 
manager node that is In-Service Active. If neither platform 
manager node is In-Service, the message will be discarded. 
Upon receiving a RoutinglnfoMsg REQUEST type mes- 
sages from the Host, ConfigMgr sends a RoutinglnfoMsg 
RESPONSE back to the Host indicating the request was 
acknowledged and attempts to retrieve the Routing Info. 
Once the Routing info is retrieved, ConfigMgr sends a 
RoutinglnfoMsg S_REPORT back to the Host with the 
routing information. ConfigMgr sends RoutinglnfoMsg 

U REPORT type messages to the Host upon request by 

another subsystem to send routing information. Upon 
receiving a request to send routing information from another 
subsystem, ConfigMgr checks the routing pending queue to 
determine if the Host requested the information. If so, 
ConfigMgr sends a RoutinglnfoMgr S_REPORT to the 
Host with the routing information. Otherwise, ConfigMgr 
sends a RoutinglnfoMsg U_REPORT to the Host with the 
routing information. After ConfigMgr sends a U_REPORT 
to the Host, ConfigMgr waits for the Host to acknowledge 
receiving the data by sending a RoutinglnfoMsg ACK 
RESPONSE. If no response is received by ConfigMgr 
within the time limit, ConfigMgr requests the appropriate 
subsystem to send the application routing information again 
(to cause a resend of the data to the Host). If a NAK 
RESPONSE is received from the Host, ConfigMgr issues an 
IPR indicating a failed response code from the Host. 

The Scheduled Action Control Message is processed by 
the platform manager node that is In-Service Active. If 
neither platform manager node is In-Service, the platform 
manager node that is OS-MIN Active will process the 
request. When SchedActCtlMsg SET type messages are 
received from the Host, ConfigMgr calls SetSchedAction 
operation of NetPM to enable/disable the scheduled actions 
(such as constant monitoring and generic audits) as desired. 
ConfigMgr sends a SchedActCtlMsg RESPONSE type back 
to the Host to indicate whether the Set was successful or not. 
ConfigMgr has a GetSchedActions operation that can be 
used by a client to get the Host time information. When this 
operation is invoked, ConfigMgr sends a SchedActCtlMsg 
REQUEST type message to the Host. ConfigMgr then sets 
up a Host Response Pending Queue entry for the desired 
SchedActCtlMsg S_REPORT from the Host. Processing (of 
GetSchedActions) is then suspended until the S_REPORT 
is received or the timer expires. No action is taken if the 
timer expires before receiving the scheduled actions. When 
ConfigMgr receives the SchedActCtlMsg S_REPORT type 
message from the Host, ConfigMgr will check if there is an 
entry for the SchedActCtlMsg S_REPORT in the Host 
Response Pending Queue. If so, ConfigMgr calls SetSche- 
dAction operation of NetPM to enable/disable the scheduled 
actions as desired. 

The Server Info Message is precessed by the platform 
manager node that is In-Service Active. If neither platform 
manager node is In-Service, the platform manager node that 
is OS-MIN Active will process the request. ConfigMgr 
sends ServelnfoMsg REQUEST and REQUEST ALL tupe 
messages to the Host during initialization processing and 
restore processing of aplatform manage rserver. After the 
message is sent, ConfigMgr suspends processing of the task 
and sets up a Host Response Pending Queue entry for a 
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ServerlnfoMsg S_REPORT type (and/or COMPLETE type 
if REQUEST ALL is used). Initialization and restore pro- 
cessing is not continued until the required Server Info is 
obtained or the timer expires. If the timer expires (before 
info is obtained) during initialization, ConfigMgr sends the 
ServerlnfoMsg REQUEST or REQUEST ALL again until 
the information is obtained. If the timer expires (before info 
is obtained) during restoral of aplatform managerserver, 
ConfigMgr issues an IPR that the restoral failed. 

When ServerlnfoMsg S_REPORT and COMPLETE 
messages are received from the Host, ConfigMgr checks if 
there is an entry for the ServerlnfoMsg S_REPORT or 
COMPLETE in the Host Response Pending Queue. If so, the 
appropriate procedure will be called to complete initializa- 
tion or restore processing. When ServerlnfoMsg CHANGE 
type messages are received from the Host, ConfigMgr 
determines if it is in an appropriate state to process a server 
info CHANGE. If so, ConfigMgr informs NetPM of 
changed server information and sends a ServerlnfoMsg 
RESPONSE type back to the Host to indicate whether the 
server information was changed successfully or not. 

The Server Status Message is processed by the platform 
manager node that is In-Service Active. If neither platform 
manager node is In-Service, the platform manager node that 
is OS-MIN Active will process the request. Upon receiving 
a ServerStatusMsg REQUEST type messages from the Host, 
ConfigMgr obtains the server and query status information 
and sends a ServerStatusMsg S_REPORT back to the Host 
with the current status information. ConfigMgr sends Serv- 
erStatusMsg UNREPORT type messages to the Host when 
server status changes occur or as required during processing 
of a Host configure server request. 

The Test Server Message is processed by the platform 
manager node that is In-Service Active. If neither platform 
manager node is In-Service, the platform manager node that 
is OS-MIN Active will process the request. If the target 
server is myself and my mateplatform manageris not halted, 
this platform manager node will discard the request while 
the otherplatform managerprocesses message. Upon receiv- 
ing a TestServerMsg REQUEST or ABORT type message 
from the Host on the MAINT logical link, ConfigMgr 
determines if the target server's status is MOS_MIN. If so, 
ConfigMgr sends a TestServerMsg Acknowledge 
RESPONSE back to the Host. In the future, ConfigMgr will 
initiate or abort the appropriate test based on whether a 
REQUEST or ABORT is received. If the target server is not 
MOS„MIN, ConfigMgr sends a TestServerMsg Server Not 
MOS-MIN RESPONSE back to the Host. If the target server 
status cannot be obtained, ConfigMgr sends a TestServ- 
erMsg Denied RESPONSE back to the Host and issues an 
appropriate IPR. 

The Time Message is processed by the platform manager 
node that is In-Service Active. If neither platform manager 
node is In-Service, the platform manager node that is 
OS-MIN Active will process the request. Upon receiving a 
TimeMsg SET type messages from the Host, ConfigMgr 
calls SetTime operation of NetPM to set the server network 
time to the appropriate time and sends a TimeMsg 
RESPONSE back to the host to indicate whether the Set was 
successful or not. ConfigMgr has a GetTime operation that 
can be used by a client to get the Host time information. 
When this operation is invoked, ConfigMgr sends a 
TimeMsg REQUEST type message to the Host. ConfigMgr 
then sets up a Host Response Pending Queue entry for the 
desired TimeMsg S_REPORT from the Host. Processing is 
then suspended until the S_REPORT is received or the 
timer expires. No action is taken if the timer expires before 
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receiving the timer information. Upon receiving a TimeMsg 
S_REPORT type message from the Host, ConfigMgr will 
check if there is an entry for the TimeMsg RESPONSE in 
the Host Response Pending Queue. If so, SetTime operation 

5 of NetPM is called to set the server network time. 
Node Management Services 
Node Platform Manager (Node 1PMM Main) 
The Node Management subsystem provides process man- 

10 agement within a single server node. It is responsible for 
starting/stopping processes within the server node to main- 
tain specific run-levels. Run-levels supported by Node Man- 
agement are 

HALTED (No software running-not even OS) 
15 MIN-SET (OS+Minimal Required Platform Software) 
INSERVlConfigurable element (MIN-SET+Common 
Software) 

Network Management informs Node Management of the 
2Q desired run-level for a specific node. In the event of a 
process failure, Node Management evaluates the failure and 
determines what, if any, recovery action is necessary. Recov- 
ery actions include ignoring the failure, autostarting the 
node to the next lower run-level and back to the current 
2s run-level, and system shutdown. 

NodePM will ve brought up as part of System start-up 
procedure for each server node. As part of its initialization, 
NodePM: 

Instantiates the NodeMAP object, and after getting the 
30 configuration information on the minimum Config- 
urable elements that need to be configured on each 
servers, it brings up the server node to a minimal 
operational state (OS-MIN). From this state the server 
node is allowed only a minimum set of functionality 
35 such as bringing the rest of the processes up. The 
configuration data provided in each node's NodeMAP 
determines the capabilities of each server node (server 
nodes withplatform managercapabilities versus server 
nodes with query processing capabilities). 
40 Creates the NodePM server object to handle the NetPM 
requests to perform operations within the same server 
node. 

Per NetPM request, NodePM (through operations pro- 
vided by its server object) can perform the following opera- 
45 rions: 

Bring up its server node to a fully operation state (IN- 
SERVlConfigurable element) from a minimal opera- 
tional state (OS-MIN) (RestoreNode operation). 
50 Bring down its server node to a minimal (OS-MIN) or 
halted (HALT) operational state from a fully opera- 
tional state (IN-SERVIConfigurable element) 
(RemoveNode operation). 
Enable/Disable the query processing on its server node. 
55 Provide status information on Configurable elements. 
NodePM reports any change of status on each IPU 
autonomously to NetPM (NodePM utilizes the operation 
provided by NetPM to report the status change). 

FIG. 8 is a diagram showing the legal service state 
60 transitions for a node. Notice that all automatic states 
transition to other automatic states and all manual states 
transition to other manual states. There is no legal transition 
from a manual state to an automatic state. The ISV state has 
no automatic or manual designation at this time. States can 
65 transition form/to IN-SERVICE (ISV) state 200 to/form any 
other state. The acronyms used in FIG. 8 are decoded as 
follows: 
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ISV 200 


in service 


OOSAM 202 


automatic out of service 




minimal 


OOSMM 204 


manual out of service minimal 


OOSAN 206 


automatic out of service- 




halted 


OOSMN 208 


manual out of service- halted 


ABOOT 210 


automatic boot 


MBOOT 212 


manual boot 


ADOWN 214 


automatic downgrade 


MDOWN 216 


manual downgrade 


AHALT 218 


automatic halt 


MHALT220 


manual halt 


AREST 222 


automatic restore 


MR EST 224 


manual restore 
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Node System Integrity (NodeSIMain) 

The Node System Integrity subsystem (class name 
NodeSI) provides fault isolation and monitoring services 
within a single server node. All process failures are logged 20 
by this subsystem and forwarded to node Management for 
recovery action. Node System Integrity implements the 
following features: 

Passive process monitoring (signal catching) 

Inter-nodal communications monitoring 

Local fault reporting 

The System Integrity (SI) capabilities of the AIN platform 
can be categorized as those providing capabilities across the 
server nodes of the platform, and those that provide capa- 
bilities within a single server node. While NetSI handles the 
system integrity capabilities at the platform level, the 
NodeSI provides system integrity at the single node level. 
NodeSI resides in every server node of the platform, and 
provides operations through which processes for each con- 
figurable element can report fault conditions on that process. 
These faults include: 

Faults detected by Constant Monitor object on each 
process. 

Inter nodal communication failures. 
Communication failures between the host and server 
network. 

Faults detected by IM Server process. 
It also performs node constant monitoring of all connections 
to/from the node. It a communication fault is detected, 
NodeSI will inform NetSI of the communication fault. 
Depending on the reported fault, NodeSI will take appro- 
priate actions, including issuing IPRs, and downgrading the 
node's state (in cooperation with the NodePM). 

NodeSI monitors the disk utilization on each server node, 
the issues appropriate IPR when the total capacity used on 
a particular file system exceeds a certain threshold. NodeSI 
communication with other objects is handled via the DOME 
interface. NodeSI gets the list of all IPUs in the configura- 
tion from NodePM. An array is set up containing the 
following information from each IPU: 

IPU information received from NodePM 

IPU status 

Fault count 

Alive message received indicator 
An array index into this list is used to communicate status 
with the other NodeSFs rather than the node name since 
string comparisons con be costly in terms of speed and 
efficiency. Therefore, it is important that each node in the 
configuration have the same IPU list in the same order. 

NodeSI registers with NodePM to get node state notifi- 
cations. When NodeSI is informed of a status change for 



another IPU, it will update the IPU status in the IPU array. 
It the status change is to the halted state, NodeSI will clear 
the fault counts and alive message received indicator. 
NodeSI has two timers to handle its constant monitoring 
5 function: 

Broadcastlimer — timer that causes NodeSI to broadcast 
"I'm alive" messages to the other NodeSFs in its view. 
ConMonChkTimer — timer that causes NodeSI to deter- 
mine if the appropriate "I'm alive" messages have been 
10 received for all connections within the time interval. 
When NodeSI is informed that is node is OS-MIN, it starts 
broadcasting "Fm alive" messages to the other NodeSFs in 
its view. It then triggers the Broadcastlimer. Upon Broad- 
castlimer expiration, NodeSI immediately rebroadcasts the 
1S "Fm alive" messages and re trigger the BroadcastTimer. This 
will interrupt any NodeSI processing that may be going on. 

When NodeSI receives an "Fm alive" message from 
another NodeSI, it marks the appropriate IPU array entry's 
Alive message received indicator. 

When NodeSI is informed that is node is OS-MIN, it 
triggers the ConMonChkTimer. Upon ConMonChkTimer 
expiration, NodeSI makes a Dome call to the Comm- 
FailCheck operation to perform communication failure 
checking and retrigger the timer. It is using the DOME call 
25 to itself in order to assure that priority is given to broad- 
casting the alive messages. 

Communication failure processing involves checking 
each IPU in its array to determine if an alive message have 
been received since the last time it checked. If so, the Alive 
message received indicator is cleared. If no message has 
been received and the IPU status is not halted, the fault count 
for that node will be incremented. If the number of faults for 
that IPU is at its maximum, NodeSI reports a communica- 
tion failure to NetSI. 

The maximum number of fault counts is a configurable 
value that can be read in from the command line by using the 
keyword "MAX_COMM_FAULXS'\ If no value is given, 
the default number of fault counts will be 2. Also, if the 
value given in the command line is less than 2, the maximum 
number will be set to 2. 

The number of seconds between each broadcast of alive 
messages is a configurable value that can be read in from the 
command line using the keyword "BRDCAST _ J ALIVE- 
SECS". If no value is given, the default number of seconds 
45 between broadcasts will be 1 second. If the value given in 
the command line is less than 1 second, the number of 
seconds will be set to 1. 

The number of seconds between each constant monitoring 
check is a configurable value that cen be read in from the 
50 command line using the keyword "CONMON__CHK__ 
SECS". If no value is given, the default number of seconds 
between checks will be 2 seconds. If the value given in the 
command line is less than 2 seconds, the number of seconds 
will be set to 2. 
55 NodeSI is started by NodePM as part of every node's 
start-up, and prior to other processes start-up. As part of its 
initialization, NodeSI reads a descriptor file (Fault.des) 
containing the definition of the faults detected by the 
NodeSI, and creates a list (FaultlnfoList) of those fault 
60 records. Each fault record (Faultlnfb) contains the following 
parts: 

Faultld— Fault Identification. 
FaultActlo 1 — Action to be taken per Fault reported. 
As faults are received, NodeSI will search for the fault 
65 record in its list (FaultlnfoList) using the fault's Id, and 
performs the action associated with that fault. These actions 
may include: 
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Issuing appropriate IPRs. 

Halting the node in case of detecting catastrophic faults 

on NodePM process. 
Reporting autonomous status changes on Configurable 

elements to NodePM. 5 
Reporting communication failures to NodePM and in turn 

to NetSI. 

All faults (originated from Constant Monitor or other 
processes) will be reported to the NodeSI by each process 10 
via Notify Fault( ) operation of NodeSI, NodeSI keeps track 
of disk utilization on the server node, and issues an IPR if 
80 was used. 
NodePM Interface 

NodeSI uses the interface provided by NodePM to report is 
the autonomous changes in a Configurable element's status 
(AutoChgCEStat( . . . )). Depending on the configurable 
element's impact on the state of the node, the status change 
may cause NodePM to perform any of the following actions: 

Downgrade Node's State — This action is performed if the 20 
configurable element's status change bad a major 
impact on the current operational state of the node. 
Prior to doing this, NodePM will inform the NetSI of 
its intent, and starts a timer. Then upon request from 
NetPM or time-out, it will downgrade the node's state. 25 

Report Communication Failure — This action is per- 
formed if the configurable element's status change 
indicated an internodal communication failure (TCP 
link goes out of service). For this situation, NodePM 
will notify NetSI of communication failure, and 30 
attempts to establish the communications again. 
NetSI Interface 

NetSI provides operations, used by NodeSI and/or 
NodePM to report the following conditions: 35 

Autonomous changes in an IPU's status 
(DowngradeIPStat( . . . )>— In this situation, NetSI 
downgrades the node through NetPM (requests NetPM 
to downgrade, if the node was not halted already). 

Communication failures (CommFaultRprt( . . . )) — In this 40 
situation, if communications failure to the same IPU 
was reported by other IPUs, then NetSI will mark that 
IPU as the IPU in fault, and attempts to downgrade it 
through NetPM. 
Constant Monitor Interface 45 

Each Configurable element process is required to instan- 
tiate the Constant Monitor object, in order to detect and 
report abnormal conditions/events generating different sig- 
nals on the process. Constant Monitor reports these condi- 
tions via NotifyFault( ) operation of NodeSI. In case of 50 
failure to communicate the fault to NodeSI, the Constant 
Monitor may HALT the node, depending on the options set 
at the time of its instantiation. 

Message Handler/Logical Links Interface 55 

Message Handler or Logical Link configurable element 
processes utilize the NodeSI operation NotifyFault( ), to 
report faults on DN1/TCP links. 
Service Manager (SM Process) 

The service management subsystem provides process 60 
control for application processes. Application processes are 
only run after the node has achieved the IN SERVICE 
run-level. Application processes can be individually 
removed/restored and enabled/disabled on a server node. 
Network management informs service management as to 65 
which applications to remove, restore, enable, disable. Fea- 
tures implemented by service management include: 
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Active Process Monitoring (Heartbeats, Audits) 
Multiple process instance support 
Application Process State Management 
Administrative State 
Operational State 
Usage State 
Application process state change notification 
For the telecom platform Navigator feature to present a 
consistent configurable element interface, a change has been 
made to have service management start System configurable 
elements instead of NodePM. By doing this, all processes in 
the system (except service management) are started by 
service management, so the features of a configurable ele- 
ment are now the same system-wide. To create a telecom 
platform Navigator GUI, a consistent view of a telecom 
platform system has to exist. FIG. 9A is a diagram that 
shows the new relationship that exists during node initial- 
ization between entities in the telecom platform. For a 
configurable element to be able to take advantage of all 
service management functionality, the service management 
interface needs to be followed. 
A boot script 230 is created to be the first thing to run on 
all nodes. When the boot program 230 runs, it will 
identify the platform manager node 232, and copy the 
active platform manager node's Tel descriptor file 234 
over to use to bring up that node. If is determines that 
it is the first platform manager node to come up, it will 
use the existing Tel descriptor file 234 to run. 
The platform manager subsystem, and the service man- 
agement subsystem 236 have a different concept of 
what a configurable element 238 is in the previous 
version of the platform. These two concepts are joined 
into one configurable element concept, merging their 
separate functionalities. To do this, the platform man- 
ager subsystem will no longer remove and restore 
configurable elements, but will inform service manage- 
ment when it wants a configurable element to be 
removed and restored. Service management will now 
be the first telecom platform program started, and will 
always start NodePM as part of its initialization. 
NodePM will then be in control of starting and stopping 
processes that same as it was before, only through the 
service management, not through the old RemoveCE 
and Restore CE functionality. 
FIG. 9 B is a message flow diagram showing node initial- 
ization into the MIN_SET state. FIG. 9C is a message flow 
diagram showing node initialization into the IN_SEVICE 
state, and FIG. 9D is a message flow diagram showing node 
initialization into the POST_ISV state. 

FIG. 10 outlines the messages protocol that is used 
between SM and a Configurable element. If a configurable 
element cannot for link a service management interface 
(SMI) object into it, service management can still start that 
configurable element, but many of the features that service 
management provides will not be available. 
Event Manager (eventmanagerimpl) 

The event manager subsystem provides the ability for a 
users to generically issue event notification to one or more 
registered parties. Multiple Event:: Manager object instances 
may exist in the system. Anode level Event: :Manager exists 
on all nodes. Other Event: :Manager instances may also exist 
to provide the ability for interested parties to register for 
events that are special to a process. The eventmanagerimpl 
program provides an Event: :Manager object instance for the 
mode that it is running on. Events that are relevant to a node 
get issued through that Event:: Manager instance. Users 
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interested in events on a particular node can bind to that Referring to FIG. 12, the IprMgrlmpl program is the 

nodes Event:: Manager instance by using that nodes name as collection point for all IPRs in a telecom platform site. This 

the Event:: Manager name. Programs can also embed an program contains the IprMgrlmpl CORBA server object. 

Event-Manager object within their program. The IprM- The IprMgrlmpl object runs on each of the active/standby 

grlmpl program is an example of a program that does this. 5 platform manager nodes. The active/standby state that the 

The IprMgrlmpl has an Event::Manager named IprEvent- IprMgrlmpl reacts to is the node level active/standby state of 

Mgr. Users that wish to receive IPR events. Users that are mc telecom platform manager nodes. The standby IprM- 

interested in a particular event may register with a particular f 1 ™/ 1 object will uapubhsh its interface and the active 

Event::Manager instance to receive that event through that IP'Mgrhnpl object will publish its CORBA interface when 

Event::Manager instance The Event:: Manager does not 10 * e ;P la )?? rm man t a * er nod f Tit ^vrv** 

• * *i * *l 1- * 4? ■ * j • t c ttm t* * doing this, client users of both the IprMgr and IPRCkent 

persistently store tbe list of reg.stered parties. If the Event- ^ ^ haye ^ IpRs gJJJ*, ^ ^ 

"Manager tries to forward an event to a Event: :Receiver that iorMerlmnl obiect 

has gone away, that Event::Receiver is removed form the ^ £vent Manager is used the IPR 

hst subsystem to distribute IPRs. This allows IPRs to be for- 
FIG. 11 shows two examples of uses for Event::Manager 15 war ded to multiple destinations. By using the Event 
250 in the telecom platform system. The eventmanagerimpl Manager, additional IPR features can be easily added to the 
252 contains the node Event: :Manager object instance 250. system without incurring interface changes. The Event Man- 
The NodePMMain telecom platform program 254 uses this ager mechanism of the IPR subsystem is currently used 
Event: :Manager 250 to issue an event when the node within the telecom platform to provide some existing IPR 
changes state. The. application program 256 then creates an 20 services. The real-time IPR GUI 270 registers , to receive 
Event: :Receiver object 268 and passed a CORBA object IPRs for the purpose of displaying IPRs as they occur. The 
reference to the register call on the "Nodel23" Event: :Man- Ipr2host program 272 registers with the IPR subsystem to 
ager 250, When NodePMMain 254 generates an event by receive IPRs and forwards them to the host. An IPR logger 
calling notify on the "Nodel23" Event:: Manager 250, that may also register to receive IPRs to log to disk. 
Event:Manager 250 will find all of the Event-Receiver 25 n& *pr2host program 272 is responsible for forwarding 
objects 258 that have registered to receive this event. Seeing I pRs ^ the host. It receives IPRs from the IprMgrlmpl's 
that the application program has registered for this event, the ^^"^^ foraa tsa host message to forward on. 
Event::Manager 250 will call the notify( ) method on that ^ j, PRs ! hat & et forwarde d Jo the host use the message 
Event::Receiver object 258 which will cause the notify ( ) f^^f**™ to forward IPRs over the IPR_ASSERT 
method to be invoked I in the ^Hcation program 256. In the 30 IpR subs has a ^ ^ 
example above, he ApphcaUon program ,256 has also reg- IPRClient ^ ^ 274 md me CORBA IPR interface 276. 
istered with the IprEventMgr Event: Manager 260 in the Tfae IPRCHent interface 27 6 exists for backward compat- 
IprMgrlmpl program 262. When NodePMMMam 254 uses Mity ^ previous PAConfigurable element releases. Once 
the IprMgrlmpl interface to issue an IPR, the IprMgrlmpl mc IPR from the IPRClient interface 274 has been 
program 262 does the lookup on that IPR and performs 35 converted by the IPRClient code, an IPR is issued using the 
verification, and calls notify ( ) on the "IprEventMgr" IprMgrlmpl CORBA interface to route the IPR to the active 
Event: :Manager 260. This cause that Event:: Manager 250 to IprMgrlmpl object. This interface still uses the 
forward the generated event to the Event: :Receiver 264 in LOCIPRDB.DSK IPR dictionary as input for converting the 
the application program 256 that was passed in the register old PAConfigurable element IPRs to the current IPR sub- 
call. 40 system format. This requires that a LOCIPRDB.DSK reside 
Application programs 256 can create their own Event- on each node that has programs that issue IPRs. The 
:: Manager with its own name the same way the IprMgrlmpl LOCIPRDB.DSK dictionary was used in the previous 
program did. Event: :Manager instances need to have unique releases to do IPR verification before IPRs were forwarded 
names in the system to prevent generating an event to the to the host. The RegisterlPR utility is used to enter IPRs into 
incorrect Event:: Manager, or to help isolate a user from 45 the LOCIPRDB.DSK dictionary. The fields in the database 
registering with the incorrect Event:: Manager. entries include: ASCII key (IPR text), host IPR number, IPR 
IPR/ALARM Services priority, number of data words used, and data word format. 

The Information and Problem Reporting (IPR) subsystem In order to test the IPRMgr, IPRs must be defined in ipr.in 

provides all processes in the system with the ability to issue which will be converted to a keyed dictionary (via the 

Information and Problem Reports. IPRs are the standard 50 RegisterlPR utility). 

mechanism used to inform users of the system about error The IprMgrlmpl interface is a CORBA IDL interface. If 

conditions or other pertinent system information. The Infor- an IPR is issued using this interface, it is not required to be 

mation and Problem Reporting subsystem implements the entered in the LOCIPRDB.DSK dictionary. When the IprM- 

collection of IPRs in the telecom platform. An alarm is a grlmpl object receives an issued IPR, it looks it up in its IPR 

mechanism which may be attached to an IPR. Alarm ser- 55 dictionary and constructs an IPR event to be issued. The IPR 

vices are not available now, but will be available in future event contains information that was passed from the client 

release of telecom platform. that issued the IPR, and information from the IPR dictionary. 

The IPR subsystem provides several features. It provides IPRs must be added to the IPR dictionary and the MegaHub 

active/standby IPR service redundancy, the ability to for- host IPR dictionaries prior to issuance of an IPRs. The 

ward IPRs to registered receivers, the ability to forward IPRs 60 IprDriver tool is used to add IPRs to the IprMgrlmpl IPR 

to the host, the ability to display IPRs in real-time, backward dictionary. The reformat and reformat^ scripts exists to 

compatibility with the legacy PAConfigurable element IPR assist in converting a VAX IPR file to a format that can be 

interface, a CORBA IPR interface, the ability to use an IPR used with the IprDriver to populate the IprMgrlmpl IPR 

dictionary to validate IPRs, the ability to provide additional dictionary. 

information about the IPR that was issued from the IPR 65 FIG. 13 illustrates the scenario where an application 

dictionary, and the ability to provision IPR in the IPR issues an IPR, the IPR Manager processes it, and the Event 

dictionary. Manager routes the IPR to an IPR GUI for visual display. 
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1) The IPR GUI registers an interest in receiving all IPRs 
reported to the IPR Event Manager. 

2) An application issues an IPR. 

3) The IPR Manager forwards the IPR to the Event 
Manager. 

4) The Event Manager distributes the IPR to the IPR GUI. 
FIG. 14 is an example of an IPR View GUI screen print. 

The IPR View GUI application provides the display of IPRs 
in a split window. In the top pane a graphical view of IPRs 
is shown with costs vs. time displayed on category basis. 
The bottom pane displays a traditional full/brief text view of 
IPRs. Subcategories may be viewed and a number of cus- 
tomizations of the display are allowed. In addition, filtering 
and highlighting are available for the IPRs displayed. Com- 
munication is handled via CORBA. 
Statistics Services 

Data Collection (DcMProcess, DcProcess) 

Referring to FIG. 15, the data collection subsystem (DC) 
298 provides the traffic measuring functionality for the 
application programs within a node. These measurements 
are counts recorded by the PegCounter class and elapsed 
time recorded by the TimeMeter class. PegCounter 299 
testing will indirectly test shared memory 300 and sema- 
phores. Client processes 301 peg to shared memory 300, and 
data collection 298 collects from shared memory 300 and 
sends to DCMaster 302. Every 30 minutes, data collection 
298 sends the DCMaster 302 (in the active platform man- 
ager node) the 30 minutes worth of peg counter slots 299 and 
then data collection zeros out those slots. The active plat- 
form manager node 304 updates the standby platform man- 
ager node 306. 

Referring to FIG. 16, the statistic services or data collec- 
tion subsystem 320 provides the traffic metering and mea- 
surement capabilities of the platform. This subsystem 320 
supports the creation, collection, and reporting of statistical 
measures like peg counters, time meters, threshold counters, 
collection and querying. PegCounters 322 and TimeMeters 
324 are shown supported across a distributed application. 
Features implemented by the data collection subsystem 320 
include: 

PegCounter 322 and TimeMeter 324 API Support 
Collection of accumulated data from multiple nodes 
Reporting GUI for local viewing of statistics 
User defined measurement sets for report customizing 
Threshold Counters (TCServer) 

The threshold counter subsystem may be implemented as 
an object request broker (ORB) distributed object, using the 
orbeline ORB implementation. Applications are connected 
via Orbeline to a server object resident in the platform 
manager nodes. The server reports counter threshold cross- 
ings to applications via distributed object messaging envi- 
ronment (DOME). The server object are created by the 
thresholds counter server process, TCServer. Each TCServer 
process also communicates via Orbeline with the TCServers 
on remote nodes so that counters can be synchronized across 
sites. The TCServer keeps all counters in persistent storage 
using the persistent dictionary supplied in the common 
services library as template class RepShmDict. 

FIG. 17 shows the communication paths between appli- 
cation processes 340 and the counter server processes. The 
TCServer process 342 communicates with application pro- 
cesses 340 via both Orbeline 344 and DOME 346. The 
TCServer process 342 runs in an orbeline impl_is_ready 
loop, waiting for service requests from either application 
processes 340 or from a TCServer process 342 on another 
node. It makes a DOME ReqServ call to notify application 
processes 340 that a counter has reached its threshold. 
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Referring to FIG. 18, the threshold counter subsystem 360 
API hides the orbeline-specific portions of the implementa- 
tion from the application programmer. Instead, the client 
side of the subsystem will consist of two layers: an ORB- 
5 independent layer 362, and an orbeline-dependent layer 364. 
Although the orbeline-specific implementation of the sub- 
system is hidden from the application programmer, the 
distributed nature of the subsystem is not. To minimize the 
time required for counter increments, counter increments are 
10 buffered in the API, and sent to the server in batches. This 
means that the application is unable to receive immediate 
notification of the success or failure of some operations on 
the API objects. 
Communications Services 
15 Message Handling (MsgHndl, LinkXXX) 

As shown in FIGS. 19 and 20, the Message Handling 
subsystem 370 provides message based interprocessor com- 
munications services. Generally all interprocess communi- 
cation between processes on the server nodes is carried out 
20 via the Distributed Object Messaging Environment (DOME) 
372 shown in FIG. 21. DOME 372 uses the Message 
Handling subsystem 370 when information must be com- 
municated across node boundaries. The Message Handling 
subsystem 370 is also used for communication to non-server 
25 external systems such as the SCP Host. The Message Han- 
dling subsystem 370 implements the following features. 
Common interface for multiple protocols. 
TCP/IP 374 
UDP/IP 376 
30 DECNET 378 

Single access identifier (Logical Link Group Name) for 

multiple links with same destination. 
Redundant link management (improves scalability) 
35 Link failure recovery 

Asynchronous receive interface 
Distributed Object Services 

Referring to FIG. 21, DOME 372 is a client/server 
interface used for interprocess client/server communication. 
40 It contains server interfaces 382 which allow server pro- 
cesses 382 to register objects and member functions for use 
by client processes 384. DOME 372 contains a shared 
memory database 380 to store the server descriptions and a 
stand-alone DOMEServices process (domeSrv) which main- 
45 tains the server object descriptions from other nodes. It also 
contains client interfaces 384 which provide access to any 
registered server object in the node's DOME database. 

The Interprocess Communications subsystem consists 
mainly of DOME. DOME provides the ability for a process 
50 to register a server object and it's methods in a way that 
allows other processes in the system to invoke those meth- 
ods. DOME supports various modes of registration and 
access including many special routing options that aid in the 
development of fault resilient software. Features imple- 
55 mented by the Interprocess Communications subsystem 
include: 

Registered Object Name Management across nodes and 
sites 

Prioritized request handling 

60 

Active/Standby Object request routing 
Load Shared Object request routing 
Broadcast Object request routing 
Blocking/Non-Blocking Object requests 
65 Common Services 

The Common Utilities subsystem provides a library of 
programming tools to aid in the rapid development of 
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processes designed to run on or within the platform layer. Event Services 

The features implemented by the Common Utilities sub- Event services provide the capability to generate and 

system include: distribute specific occurrences significant to a task among 

Command Line Object loosely coupled processes. An example of an event is the 

Trace Ob'ect 5 com P^ e ^ on °f an input/output transfer. The event services 

may be a CORBA-based interprocess communication facil- 

Shared Memory Object ity It uscs sta ndard CORBA requests that result in the 

Semaphore Object execution of an operation by an object. This is accomplished 

Keyed Dictionary Object through the event manager implemementation program. 

List Object 10 By defining two distinct roles for objects, communication 

Replicated Keyed Dictionary Object * de .«> u Pl ed Ejects; creating .asynchronous com- 

J mil ni cat ioo. One object receives and accumulates new 

Shared Memory Dictionary Object eventSj while tQe Qther object ^gstus an interest to be 

etc. forwarded these new events. This is accomplished by two 

DbgTrace Object 15 CORBA classes, EventManager and EventReceiver. Event- 

Referring to FIG. 22, the DbgTrace faculties 400 provides Manager provides an interface definition language (IDL) 
the ability to issue trace messages to a trace buffer, to a file, interface for receiving new events. EventReceiver provides 
and/or to standard error. Trace data can be entered in two an interface definition language interface for clients inter- 
different formats: standard print format, and a data buffer ested in receiving events, 
dump format. A mask 402 may be used to filter out different 20 Software and Hardware Representation 
levels of messages. There are 32 possible mask levels for FIG. 24 shows the hardware view of a telecom platform 
each DbgTrace group. system. At the highest level, a telecom platform system 

The DbgCntl interface 404 is the control interface for consists of one or more sites 440. Within a site 440, multiple 
DbgTrace objects 400. It allows users to specify many nodes 442 exist. 

different aspects of the DbgTrace facility 400. This interface 25 The software representation is a hierarchy allowing com- 
allows users to do the following things on DbgTrace objects ponents of software to be grouped together. FIG. 25 shows 
400: this hierarchy. An Application 450 exists at the highest level. 

Set/Get the mask 402 for a DbgTrace group 400. M Application 450 is made up of one or more configurable 

OWt . . r .i_ . * 1 , ff ..a element sets 452, which is made up of one or more config- 

Set/get the size of the internal message buffer 410. L1 , t a* a w i.* 1 t* ^ 

& & 30 urable elements 454. Multiple applications 450 can be 

Get a list of existing groups. defined within a system. All of the applications 450 within 

Turn on/off display to standard error. a system make up the software representation of a system. 

Turn on/off dumping of traces one at a time to a file. The dynamic mapping of software onto hardware repre- 

Enable/disable the ability to dump traces out to file before sentation of a system shown in FIG. 26 depicts how pieces 
they get overwritten 35 °^ 311 a PP ucauon 450 are placed onto nodes 442. Sites 440 

A DbgDisk interface allows users to specify which file the ***** VP^sSon 450. Applications 450 have processor 

trace buffer 410 will be written to on all write requests. ■ e ™* 1 S™P S < 5 , 6 J? 0 **??! J*™™ &™P** S6 t S P™ 

Tie DbgTrace facility 400 allows the users to create ™ ltl £ 442 • Nod <* 442 have configurable element 

j-rr t rZ t u- * Ann *u * u u i * sets 452 placed on them. Configurable elements 454 reside 

different Dbg I race obi ects 401) that can each belong to one r - _ , _ 

c i J. j * . ,40 within configurable element sets 452. For example, a soft- 

or multiple groups. I nis allows users to have a unique mask * * j V 

i r t. i ii . . , 4 . * .i t" ware representation of a time dependent routing application 

value for each group. All traces issued through the DbgTrace _ u * c ut i * . w .e » j 

• „ _r 4*vn * / j- • * i • rc w t may have two configurable element sets: WestCoastSet and 

interface 400 get stored in an internal message buffer. Users r, \~. . „ 7 ~ t „ fc t , . , . . 

, 5. l *u * • * . * j j EastCoastSet. Within the WestCoastSet, the time dependent 

can also specify whether to issue traces to standard error in 4 . , , . „ J . , 

„ v . ,i • , , , a routing application could have all of the programs that need 

addition to the internal buffer. , & r \, , . « « . j— i , n 

45 to run on the nodes targeted to handle West Coast calls. 

race jec These might include database programs, link processes, etc. 

The Trace object provides the user the ability to optionally mat m configured specifically for West Coast handling, 

issue trace messages to standard error. When the user issues Within me EastCoastSet, the time dependent routing appli- 

a trace, a mask is specified which represents the trace level cation may have all of me programs that need to run on the 

that this trace will be output for. The Trace interface allows 50 aodes tar g e ted to handle West Coast calls. The time depen- 

the user to specify a mask which all instances of trace in that deQt routing applica tion would then be allocated onto a site. 

UNIX process will use to determine whether or not to issue Nodes mal ^ ran me Ume depend ent routing application 

the trace message. The trace mask may supports eight wiu ^ gr0U ped into processor service groups. The config- 

unique mask values. urable element sets for the application would then be placed 

Dictionary Management System 55 on nodes that have been placed into a time dependent routing 

Referring to FIG. 23, Dictionary Management provides application processor service group, 

classes which are designed to support data storage and Although several embodiments of the present invention 

access. Dictionaries can be stored on disk (persistent) or and its advantages have been described in detail, it should be 

stored in memory. Dictionaries can also be private (used by understood that mutations, changes, substitutions, 

local process only) or shared (accessible by multiple 60 transformations, modifications, variations, and alterations 

processes). The purposes of these dictionaries are defined by can be made therein without departing from the teachings of 

the apphcation program. The primary interaction between the present invention, the spirit and scope of the invention 

DmsMaster 430 and DmsServer 432 is that DmsMaster 430 being set forth by the appended claims, 

updates DmsServer 432 when it receives an update message What is claimed is: 

from the application. DmsMaster 430 runs as active/standby 65 1. A method of providing a software interface between 

in the platform manager nodes, and DmsServer 432 runs in apphcation programs performing telecommunications func- 

all (or a subset) of the IPUs. tions and an operating system running on at least one node 
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at a site supporting the application programs, and further 7. The method, as set forth in claim 3, further comprising: 

forming an interface between the application programs and registering with an event manager, by an application, an 

a telecommunications network, comprising: interest to receive a particular event; 

supplying network management processes operable to sending, by an event receiver, the particular event to the 

provide inter-node configuration, monitoring and man- 5 registered application. 

agement functionality; 8. The method, as set forth in claim 1, further comprising: 

supplying node management processes operable to pro- running the network management processes on at least 

vide node initialization, configuration, monitoring, and one platform management node; and 

management functionality; ^ running the node management processes on at least one 

supplying event processes operable to provide application node coupled to the at least one platform 

initialization, termination, and distribution of tasks in management node. 

response to predetermined events; 9. The method, as set forth in claim 8, further comprising 

supplying common processes operable to provide a running the network management processes and the node 

library of a plurality of programming tools for the JS management processes on a platform management node also 

development of the application programs; serving as an application node, 

supplying communications processes operable to provide 10- The method, as set forth in claim 8, further compris- 

message handling functionality; and ing: 

supplying distributed object processes operable to provide operating a first platform management node in an active 

a distributed database repository for object-based com- 20 mode; and 

munications. operating a second platform management node in a 

2. The method, as set forth in claim 1, wherein providing standby mode. 

the network management processes comprise: 11. The method, as set forth in claim 8, further comprising 

providing a network platform manager operable to operating two or more platform management nodes operat- 

remove nodes from service, restore nodes to service, 25 ing in a load-sharing mode. 

remove applications from service, and restore applica- 12. The method, as set forth in claim 1, further comprising 

tions to service; supplying statistics processes operable to provide methods 

providing a network system integrity manager operable to to access svslem measurement data and to generate reports 

monitor the nodes and to enable failed nodes to on the system measurement data. 

recover and 30 ^ De method, as set forth in claim 12, wherein sup- 
providing a configuration manager operable to interface P 1 *** statistics comprise: 

with a host coupled to the telecom platform. provLding a peg counter process operable to count specific 

3. The method, as set forth in claim 2, wherein providing evenls occurring across multiple nodes; 

the node management processes comprise: providing a time metering process operable to accumulate 

providing a node platform manager operable to provide 35 A f duration of a specific event; 

management functions for a node; providing a data collection process operable to collect 

providing a service manager operable to start and stop counter data on a node and storing the collected data, 

processes at the direction of the node platform man- 14 mctnod > ^ 501 form m cIaim father comprising 

ager and supplying information and problem report and alarm pro- 

providing a node system integrity manager operable to *° c f sses °P« abl * to P«> vide «kk edition monitoring, 

monitor inter-node links. alarms and reporting. 

4. The method, as set forth in claim 3, comprising: 15 The method, as set form mclaunl r^ercompnsmg 

. . , , , . * , , supplying dictionary processes operable to provide data 

monitoring and detecting a failure in a configurable &{ ^ & * d access memodSi ^ 

element; 45 16 The memo d, as set forth in claim 1, further comprising 

notifying the fault to the service manager; supplying graphical user interface processes operable to 

generating, by the service manager, a status change for the provide graphical user interface building methods. 

configurable element and forwarding the notification to 17. The method, as set forth in claim 1, wherein providing 

the node system integrity manager; the event processes comprise: 

forwarding, by the node system integrity manager, the 50 providing an event manager operable to register client 

notification to the node platform manager; processes wishing to receive events; and 
determining, by the node platform manager, the node providing an event receiver operable to provide an inter- 
status in response to the failed configurable element; face for client processes which are registered to receive 
and 5S events, 
notifying the net platform manager, by the node platform 18. The method, as set forth in claim 1, wherein providing 
manger, of a node status change. the common processes comprise providing a timer manager 

5. The method, as set forth in claim 4, further comprising: operable to provide date and time functionality, 
determining, by the network platform manager, a status ^ method, as set forth in claim 1, further compris- 

change in an application having the failed configurable 60 m £ : 

element and a status change in a processor service running a boot script; 

group having the application having the failed config- starting a service manager in accordance to the boot 

urable element; and script; 

notifying any status change to the configuration manager. starting, by the service manager, a node platform manager 

6. The method, as set forth in claim 5, further comprising 65 for a node; 

forwarding, by the configuration manager, a node, processor starting, by the service manager, PRE-MIN configuration 

service group or application status change to a host. elements for the node; 
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starting, by the service manager, OS-MIN configuration 

elements for the node; and 
upgrading a state of the node in response to the OS-MIN 

configuration elements in the node. 

20. A telecom platform forming an interface between 5 
application programs performing telecommunications func- 
tions and an operating system running on at least one node 

at a site supporting the application programs, and further 
forming an interface between the application programs and 
a telecommunications network, comprising: 10 
network management processes operable to provide inter- 
node configuration, monitoring and management func- 
tionality; 

node management processes operable to provide node 
initialization, configuration, monitoring, and manage- 15 
ment functionality; 

event processes operable to provide initialization, 
termination, and distribution of tasks in response to 
predetermined events; 

common processes operable to provide a library of a 20 
plurality of programming tools for the development of 
the application programs; 

communications processes operable to provide message 
handling functionality; and 

distributed object processes operable to provide a distrib- 25 
uted database repository for object-based communica- 
tions. 

21. The telecom platform, as set forth in claim 20, further 
comprising: 

at least one platform management node on which network 30 
management processes are supported; 

at least one application node coupled to the at least one 
platform management node on which oode manage- 
ment processes are supported. 3S 

22. The telecom platform, as set forth in claim 21, wherein 
the at least one platform management node is also the at least 
one application node. 

23. The telecom platform, as set forth in claim 21, wherein 
the at least one platform management node comprises: ^ 

a first platform management node operating in an active 
mode; and 

a second platform management node operating in a 
standby mode. 

24. The telecom platform, as set forth in claim 21, wherein 4S 
the at least one platform management node comprises two or 
more platform management nodes operating in a load- 
sharing mode. 

25. The telecom platform, as set forth in claim 20, further 
comprising statistics processes operable to provide methods 50 
to access system measurement data and to generate reports 
on the system measurement data. 

26. The telecom platform, as set forth in claim 25, wherein 
the statistics processes comprise: 

a peg counter process operable to count specific events 55 
occurring across multiple nodes; 

a time metering process operable to accumulate the dura- 
tion of a specific event; 

a data collection process operable to collect counter data 
on a node and storing the collected data. 60 

27. The telecom platform, as set forth in claim 20, further 
comprising information and problem report and alarm pro- 
cesses operable to provide error condition monitoring, 
alarms, and reporting. 

28. The telecom platform, as set forth in claim 20, further 65 
comprising dictionary processes operable to provide data 
storage and access methods. 
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29. The telecom platform, as set forth in claim 20, further 
comprising graphical user interface processes operable to 
provide graphical user interface building methods. 

30. The telecom platform, as set forth in claim 20, wherein 
the network management processes comprise: 

a network platform manager operable to remove nodes 
from service, restore nodes to service, remove appli- 
cations from service, and restore applications to ser- 
vice; 

a network system integrity manager operable to monitor 
the nodes and to enable failed nodes to recover; and 

a configuration manager operable to interface with a host 
coupled to the telecom platform. 

31. The telecom platform, as set forth in claim 20, wherein 
the node management processes comprise: 

a node platform manager operable to provide manage- 
ment functions for a node; 

a service manager operable to start and stop processes at 
the direction of the node platform manager; and 

a node system integrity manager operable to monitor 
inter-node links. 

32. The telecom platform, as set forth in claim 20, wherein 
the event processes comprise: 

an event manager operable to register client processes 

wishing to receive events; and 
an event receiver operable to provide an interface for 

client processes which are registered to receive events. 

33. The telecom platform, as set forth in claim 20, wherein 
the common processes comprise a timer manager operable 
to provide date and time functionality. 

34. A method of providing a software interface between 
application programs performing telecommunications func- 
tions and an operating system running on at least one node 
at a site supporting the application programs, and further 
forming an interface between the application programs and 
a telecommunications network, comprising: 

providing a network platform manager operable to 
remove nodes from service, restore nodes to service, 
remove applications from service, and restore applica- 
tions to service; 

providing a network system integrity manager operable to 
monitor the nodes and to enable failed nodes to 
recover; 

providing a configuration manager operable to interface 
with a host coupled to the telecom platform; 

providing a node platform manager operable to provide 
management functions for a node; 

providing a service manager operable to start and stop 
processes at the direction of the node platform man- 
ager; and 

providing a node system integrity manager operable to 
monitor inter-node links. 

35. The method, as set forth in claim 34, comprising: 
monitoring and detecting a failure in a configurable 

element; 

notifying the fault to the service manager; 

generating, by the service manager, a status change for the 

configurable element and forwarding the notification to 

the node system integrity manager; 
forwarding, by the node system integrity manager, the 

notification to the node platform manager; 
determining, by the node platform manager, the node 

status in response to the failed configurable element; 

and 
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notifying the net platform manager, by the node platform 
manger, of a node status change. 

36. The method, as set forth in claim 35, further com- 
prising: 

determining, by the net platform manager, a status change 
in an application having the failed configurable element 
and a status change a processor service group having 
the application having the failed configurable element; 
and 

notifying any status change to the configuration manager. 

37. The method, as set forth in claim 36, further com- 
prising forwarding, by the configuration manager, a node, 
processor service group or application status change to a 
host. 

38. The method, as set forth in claim 34, further com- 
prising: 

providing an event manager operable to register client 

processes wishing to receive events; and 
providing an event receiver operable to provide an inter- 20 

face for client processes which are registered to receive 

events. 

39. The method, as set forth in claim 34, further com- 
prising providing a timer manager operable to provide date 
and time functionality. 

40. The method, as set forth in claim 34, further com- 
prising: 

providing a peg counter process operable to count specific 
events occurring across multiple nodes; 



25 



38 



providing a time metering process operable to accumulate 

the duration of a specific event; 
providing a data collection process operable to collect 

counter data on a node and storing the collected data. 

41. The method, as set forth in claim 34, further com- 
prising: 

running a boot script; 

starting a service manager in accordance to the boot 
script; 

starting, by the service manager, a node platform manager 
for a node; 

starting, by the service manager, PRE-MIN configuration 

elements for the node; 
starting, by the service manager, OS-MIN configuration 

elements for the node; and 
upgrading a state of the node in response to the OS-MIN 

configuration elements in the node. 

42. The method, as set forth in claim 34, further com- 
prising: 

registering with an event manager, by an application, an 

interest to receive a particular event; 
sending, by an event receiver, the particular event to the 

registered application. 
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PROCESS AND ARCHITECTURE FOR USE 
ON STAND-ALONE MACHINE AND IN 

DISTRIBUTED COMPUTER 
ARCHITECTURE FOR CLIENT SERVER 
AND/OR INTRANET AND/OR INTERNET 5 
OPERATING ENVIRONMENTS 

RELATED APPLICATIONS 

This application is a continuation-in-part application of 
U.S. patent application Ser. No. 08/911,083 filed on Aug. 14, 
1997, to the same applicant, and hereby incorporated by 
reference. 

This application is related to, and claims priority from, the 
following copending provisional applications, the details of 15 
which are hereby incorporated by reference: COMPUTER 
PROCESS FOR IMAGE CONTROL, Applicant: Laurence 
C Klein, Filed: Oct. 18, 1996, Serial Number 60/028,129; 
COMPUTER PROCESS FOR IMAGE CONTROL, Appli- 
cant: Laurence C. Klein, Filed: Oct. 18, 1996, Serial Number 2 o 
60/028,522; COMPUTER PROCESS FOR ENGINE 
BENCHMARKING, Applicant: Laurence C. Klein, Filed: 
Oct. 18, 1996, Serial Number 15 60/028,128; COMPUTER 
PROCESS FOR DESK TOP IMAGING, Applicant: Lau- 
rence C. Klein, Filed: Oct. 18, 1996, Serial Number 60/028, 15 
697; COMPUTER PROCESS FOR IMAGE VIEWING, 
Applicant: Laurence C. Klein, Filed: Oct. 18, 1996, Serial 
Number 60/028,639; COMPUTER PROCESS FOR 
IMAGE CAPTURE, Applicant: Laurence C Klein, Filed: 
Oct. 18, 1996, Serial No. 60/028,685. 30 

FIELD OF THE INVENTION 

The present invention is generally related to a computer 
architecture and process for image viewing in a stand-alone 
and/or distributed environment, and more particularly to a 35 
computer architecture and process for image viewing using 
a substantially uniform management in a stand-alone and/or 
distributed computing environment including, for example, 
client server and/or intranet and/or internet operating envi- 
ronments. 40 

BACKGROUND OF THE RELATED ART 

A"C* or "C++ W -Level API (hereinafter "C Level), which 
is the native language and interface for a vast repository of 45 
core technologies from small software vendors and research 
laboratories, are unique to each designer. The designer of a 
text retrieval "C"-API will generally implement an interface 
that is completely different than a second inventor creating 
a "C'-level API for OCR. 5Q 

Every "C'-level API is unique, both in its choice of API 
syntax as well as its method for implementing the syntax. 
Some API's consist of one or two functions that take 
parameters offering options for different features offered by 
the technology. Other APIs consist of hundreds of functions 55 
with few arguments, where each function is associated with 
a particular feature of the core technology. Other APIs 
provide a mixture of some features being combined with one 
function with many arguments, while other features are 
separated into individual function calls. 6 q 

Without any constraints, each designer of a core technol- 
ogy chooses to implement his or her technology with an 
interface that is suitable to the subject or simply was the 
most expedient choice of the moment. Since there are no 
constraints, a "C-level API has a totally unpredictable 65 
interface that can often be the hindrance to using the core 
technology. 
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Additionally, every API manages errors differently further 
complicating the problems described above. Some APIs 
return a consistent error code for each function. Error 
management in this case is very organized and manageable. 
Other APIs return error codes as one of the parameters 
passed to the function. There are APIs that mix the choice of 
error management and have some functions return an error 
code while other functions pass the error code as a parameter 
of a function. Errors can also be managed by a callback 
function, eliminating the need for passing any error code as 
part of the function. In some instances of a poorly imple- 
mented API the errors are not passed back at all. 

Every engine, such as a text retrieval or an OCR (Optical 
Character Recognition) engine, has a unique interface. This 
interface is generally a "C'-level API (Application Program 
Interface). Further, an API can at any time be synchronous, 
asynchronous, manage one or more callbacks, require input, 
pass back output, carry a variety of different styles of 
functions, return values or not return values, and implement 
the unpredictable. This unpredictability in APIs further 
compounds the problem of developing a sane way of inter- 
facing between components and APIs. 

To date, because of the complexities of "C'-level APIs 
and components interfacing thereto, the only way to create 
a component out of an existing "C'-level API is to have an 
experienced programmer in the field to do the work. Humans 
can intelligently analyze an API, and create a component 
based on intelligent decisions and experiences. In most 
cases, the learning curve for understanding and integrating 
a new engine can be one man-month to several man-years 
and generally requires highly experienced "C" program- 
mers. Requiring a human to perform the necessary work is 
costly, and subject to real-life human constraints. 

Since there is no structure or format for implementing 
"C'-level APIs, the ability to automatically transform a 
unique API into a standard component would seem 
impossible, since that would take a nearly-human level of 
intelligence. 

I have determined that a component factory, if it is to be 
truly automated or manually expedited, must be able to take 
any "C'-level API and transform it into a component. 

I have also determined an efficient and workable design 
for an architecture to define the migration path for any 
"C'-level API into a component. 

I have also determined that it is desirable to develop 
software tools for automatically generating reusable soft- 
ware components from core software technologies, thus 
making these software technologies available to a much 
larger user base. 

I have further determined that it is desirable to design a 
distributed computer architecture and process for manually 
and/or automatically generating reusable software compo- 
nents. The computer architecture may be implemented using 
a client server and/or intranet and/or internet operating 
environments. 

I have further determined that it is desirable to design a 
computer architecture and process for image viewing in a 
stand-alone and/or distributed environment. The computer 
architecture and process optionally uses a substantially 
uniform management layer in a stand-alone and/or distrib- 
uted computing environment including, for example, client 
server and/or intranet and/or internet operating environ- 
ments. 

SUMMARY OF THE INVENTION 
One would expect the translating a "C-level API from its 
native state into a component would require human-level 
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intelligence. This is mainly because "C'-level APIs have the various tiers of the architecture resulting in a standard- 

virtually no constraints as to how they can be implemented. ized component. Advantageously, the method described 

This means that there are an infinity variations of APIs, herein does not base the component factory on making 

which can only be managed by human-level intelligence. human-level intelligent decisions on how to translate a 

While this point is true, I have determined that the appro- 5 "C"-API into a component. Rather, by creating a well- 

priate solution starts at the other side of the equation, which defined architecture described below that is multi-tiered, the 

is the component itself method is a series of incremental steps that need to be taken 

w . . * . c - , to migrate the "C*- API from one tier within the architecture 

My solutxon starts out with a definition of a component to Iq ^ each mcremenlal st fe not a major 

that can sustam the feature/function requirements of any QQ ^ but in the entire of steps ^ result ^ 

API. In other words, the interface of a generic component i° a com ponenL 

can be defined such that the features and functions of since each step of migration ^ Qot a major one , the 

virtually any API can be re-implemented withm its bounds. chanccs f or automating these steps is significantly higher 

The two known end-points are, for example, the "C'-level and the likelihood of being able to create the component 

API that generally starts with each component (although factory becomes feasible. This approach is in fact what 

other programming languages may also be used and are 15 ma te S the method cost-effective, since the alternative 

within the scope of the present invention), and the compo- approach, i.e., computer-generated human-level decision 

nent interface that represents any set of features/functions on making, has many years before becoming sophisticated 

the other side. The component factory migrates the original enough to replace humans in any realistic decision-making 

"C'-level API from its original state into the generic inter- process. 

face defined by the topmost layer. The first feature that can 20 The main features of the architecture are twofold: 

be demonstrated is that there is a topmost layer that can 1) Defining system architecture that describes in detail 

define a component interface that can represent the features/ how to implement a component from a "CMevel API; 

functions of most core technologies. 2) Creating a component factory by automating the migra- 

The component factory migrates the "C'-level API to the tion of a "C-level API from one tier within the 

topmost level. Doing this in one large step would be 25 architecture to the next. The latter feature is the key to 

impossible since the "C'-level API has a near-infinite vari- actually making the component factory feasible. With a 

ety of styles. However, the architecture advantageously has architecture that can be used to implement a 

enough well-defined and well-structured layers for imple- "C-level API as a component (using a programmer), 

menting the topmost component interface, for creating the that »™ architecture can be used as the basis for the 

component factory. 30 component factory model. 

™ A , * j • j f • In order to make the component factory, each step of the 

The computer architecture is designed for managing a , . , , t , . . ~ . # - ' ' , 

* c • j * . * u i * - JL*\ architecture needs to be designed to facilitate automation or 

diverse set of independent core technologies ( engines) „ , _ . & , T , . . , . t 

. , • * * i u-* -* u i manually expedited. In other words, I have determmed that 

using a single consistent framework. The architecture bal- J , it _ c * i * • * i 

• , . •—♦*u a ♦ automating/expediting the process of taking the original 

ances two seemingly opposing requirements: the need to ,,^„ , , • * T i t r j 

. . • , • ; ♦ ■ . J! ♦ a w .35 "C -level API and migrating it to a Level 1 layer, and then 

provide a single consistent interface to many different _ . . _ , ~ , 4 f * ■ ~> * / in 

• iL * »u * *, e u a Level 1 to a Level 2, and then a Level 2 to a Level 3 layer, 

engines with the ability to access the unique features of each . t . , L • i * j , *■ 

e . J ^ and so on, the component has been implemented automati- 
en&ine 

* ' „ „ t . . , , , cally or more efficiently. The component factory is therefore 

Hie benefit of the architecture is that it enables a company a sum of ^ ^ tQ autQmate migrating the « C »-level API 

to rapidly "wrap" a sophisticated technology so that other ^ from one , a to me ^ a welMefined architecture 

high-level developers can easily learn and implement the for imp i ementing components. 

core technology. The computer architecture is therefore a are numer ous core technologies, such as text- 
middleware or enabling technology. ^Xricvzi and ICR (Intelligent Character Recognition), that 

Another benefit of the architecture is that it provides a nave afr^y been implemented, and are only available as 

high-level specification for a consistent interface to any core 45 "C"-Ievel APIs. Many, if not most, core technologies are first 

technology. Once a high-level developer learns the interface released exclusively as "C'-level APIs. While there are 

described herein for one engine, that knowledge is easily integrators and corporations who have the team of technolo- 

transferable to other engines that are implemented using the wno ^ integrate these "C'-level APIs in-house, most 

architecture. For example, once a high-level developer companies are looking for component versions that can be 

learns to use the computer architecture for OCR (Optical 50 implemented at a much higher level. 

Character Recognition), using the computer architecture for Therefore, many of the core technologies that are only 

other engines, such as barcode recognition or forms available in a "C'-level API are not being used due to their 

processing, is trivial. inaccessible interface. The benefit of the component factory 

The architecture described herein is, at once, a framework is that it can rapidly make available core technologies 

for rapidly wrapping sophisticated technologies into high- 55 implemented as "C* APIs that would otherwise be undent ti- 

level components, as well as a framework for high-level lized or dormant in research labs by converting them to 

developers to communicate with a diverse set of engines. high-level components that can be used by millions of 

The creating of a component factory is based on the fact that power-PC users. 

the architecture defines a clear path for "wrapping** any With the advent of the World Wide Web (WEB) this 

C-level API into a component using simple structures and 60 opportunity has increased exponentially. The WEB is now 

many rote steps. This process is currently being done in an home to a vast number of WEB authors with minimal formal 

inefficient manner by a programmer in the field. training who can implement HTML pages and build web 

In addition, the method described herein for creating a sites. One of the fundamental technologies for extending the 

component factory creates a well-defined multi-tiered archi- capability of the WEB from simple page viewing to inter- 

tecture for a component and automates, substantially 65 active and sophisticated applications is components, 

automates, or manually expedites hereinafter automate the A component extends the capability of HTML by enabling 

process of migrating a" C- API from its native state through a WEB author to add core technology as a pre-packaged 
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technology. Since components are fundamental to the Application Programmer Interface (API) from an original 

growth and usability of the WEB, having a component state into a generic interface by building an object for each 

factory that can translate "C"-level toolkits into components engine. The object provides substantially uniform access to 

that are then usable within WEB sites opens a vast and new the engine and engine settings associated with the engine, 

worldwide market to these technologies. 5 The computer implemented process includes the step of 

It is a feature and advantage of the present invention to providing an engine management function interfacing with 

implement a component factory, that is automated or manu- mc program specific API. The engine management function 

ally expedited. furnishes a protective wrapper for each function call asso- 

It is another feature and advantage of the present inven- ciated ^ the ^ trapping errors, and provides error 

tion to be able to take any «C -level API and transform it %Q managemeat ^ adm i nist ration to prevent conditions asso- 

mto a component. d t d with ^j™,. engine functioning. The process 

It is another feature and advantage of the present mven- . . . J f. , 6 - ... . fi 

tion to define an efficient and workable design for an °P loa ^ mcludes th f of P£ vld *S aQ ™&™«>^- 

architecture to provide the migration path for a^y C-level ra *° n furKUon transforming API caUs received from the 

API into a component. P ro S raiD s P ecific ^ into standardized caUs^The engine 

It is another feature and advantage of the present inven- 15 configuration function provxdes additional functionality, 

tion to develop software tools for automatically generating including safely loading and unloading the engine. The 

reusable software components from core software technolo- process optionally includes the step of providing an engine 

gi es function managing the standardized calls for each engine, 

It is another feature and advantage of the present inven- thereby providing substantially uniform access to the engine 

tion to develop software tools to make software components 20 and the engine settings associated with the engine, 

available to a much larger user base. In accordance with another embodiment of the invention, 

It is another feature and advantage of the present inven- a computer implemented method migrates at least one 

tion in providing a distributed computer architecture and program specific Application Programmer Interface (API) 

process for manually and/or automatically generating reus- from an original state into a generic interface by building an 

able software components. 25 object for each engine. The object provides substantially 

It is another feature and advantage of the present inven- uniform access to the engine and engine settings associated 

tion in providing a distributed computer architecture and with the engine. The computer implemented method 

process for manually and/or automatically generating reus- includes the steps of defining a substantially consistent 

able software components where the computer architecture interface for individual object components that represent 

is implemented using a client server and/or intranet and/or 30 diverse technologies, and migrating a plurality of engines to 

internet operating environments. the consistent interface. The computer implemented method 

It is another feature and advantage of the present inven- also includes the step of substantially automatically and/or 

tion in providing a computer architecture and process for substantially uniformly, managing the individual object 

image viewing in a stand-alone and/or distributed environ- components using a predefined object manager and the 

ment. 35 consistent interface. 

It is another feature and advantage of the present inven- Id accordance with another embodiment of the invention, 

tion in providing a computer architecture and process that a computer architecture migrates at least one program spe- 

uses a substantially uniform management layer in a stand- cific Application Programmer Interface (API) from an origi- 

alone and/or distributed computing environment including, nal state into a generic interface by building an object for 

for example, client server and/or intranet and/or internet 40 each engine. The object provides substantially uniform 

operating environments. access to the engine and engine settings associated with the 

The present invention is based, in part, on my discovery engine. The computer architecture includes an engine man- 
that it is possible to make the component factory, and that agement layer interfacing with the program specific API and 
each step of the architecture is designed to facilitate auto- providing engine management and administration, an engine 
mation or manually design of components. The present 45 configuration layer transforming API calls received from the 
invention is also based, in part, on my discovery that by program specific API into standardized calls, and an engine 
automating/expediting the process of taking the original layer managing the standardized calls for each engine. 
"C-level API and migrating it to a Level 1 layer, and then In accordance with another embodiment of the invention, 
a Level 1 to a Level 2, and then a Level 2 to a Level 3 layer, an engine management layer configures a computer archi- 
and so on, the component has been implemented automati- 50 tecture to perform one or more computer implemented or 
cally and/or more manually efficiently. The component computer assisted operations. The computer operations 
factory is therefore a sum of the ability to automate migrat- include one or more of loading and unloading engine 
ing the "C-level API from one layer to the next within a dynamic link libraries into and out of memory for each 
well-defined architecture for implementing components. engine, mapping at least one engine function to at least one 

The present invention is also based, in part, on my 55 corresponding engine object, providing general error detec- 

discovery that the object manager and engine object com- tion and error correction for each engine, determining and 

ponent layers may be advantageously be designed to operate matching arguments and returning values for mapping the at 

independently, thereby making possible a distributed com- least one engine function to the at least one corresponding 

puting environment, as described below in detail. I have engine object, and/or managing error feedback from the at 

further discovered that an efficient method of implementing 60 least one program specific API. 

the engine object component layer is by using pre-populated In accordance with another embodiment of the invention, 

tables/files. I have further discovered that the engine man- a distributed computer system migrates a program specific 

agement layer may be advantageously divided into a three Application Programmer Interface (API) from an original 

layer structure of load/unload engine, dynamic linking state into a generic interface by building an object for each 

engine function calls, and initialize engine setting. 65 engine. The object provides substantially uniform access to 

In accordance with one embodiment of the invention, a the engine and engine settings associated with the engine, 

computer implemented process migrates a program specific The distributed computer system includes a server config- 
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ured to include at least one engine having an engine interface FIG. 3 is an overview of the computer architecture in the 

providing one or more features to be executed, and at least present invention; 

one engine component configured to execute the one or pio 4 is an illustration of the design of an Object in 
more features of the engine by mapping a substantially accordance with the computer architecture of the present 
consistent interface to the engine interface of the engine. The 5 invention- 
distributed computer system also includes at least one client \ , 1t . r , .. . 
configured to be connectable to the server and optionally h FIG ' 5 15 a ° Oration of the architecture comprised of 
configured to be connectable to another server. The client ™° major parts, 

includes an object manager layer communicable with and FIG. 6 is an illustration of the architecture of an engine 

managing the at least one engine component stored on the component including, for example, three layers designed to 

server via the substantially consistent interface. migrate the original API of the engine to a consistent COM 

In accordance with another embodiment of the invention, interface; 

a distributed computer implemented process migrates a piG. 7 is a table illustrating the engine management 

program specific Application Programmer Interface (API) specification with definitions; 

from an original state into a generic interface by building an nG g fc an mustration of the ine maDageme nt layer 

object for each engine. THe object provides substantially ^ ^^ns/^ecifications; 

uniform access to the engine and engme settings associated 6 r 

with the engine. The computer implemented process FIG. 9 is an illustration of exemplary tables used to drive 

includes the step of providing, on a server, at least one toe thr f e functions of the engine management layer illus- 

engine having an engine interface, and providing one or trated in FIG. 8; 

more features to be executed. The computer implemented 20 FIG. 10 is an exemplary table illustrating the engine 

process also includes the step of providing, on at least one configuration specification with definitions; 

of the server and another server connectable to the server, at FIG. 11 is another exemplary table illustrating the engine 

least one engine component configured to execute the one or configuration specification; 

more features of the engine by mapping a substantially fjq. 12 is an exemplary table illustrating the engine 

consistent interface to the engine interface of the engine. The 25 functionality specification with definitions; 

computer implemented process also includes the step of F]G u fa exemplary table illustrating the engine 

providing, on a client configured to be connectable to the functionality specification; 

server and optionally configured to be connectable to the ~ „ - A . . n . ^ r . . . . 

F , J . 6 , ... ... FIG. 14 is an illustration of a main central processing unit 

another server, an obiect manager layer communicable with r ■ 1 *• *i_ * - _\ 

. . . 1 * * . « for implementing the computer processing m accordance 

and managing the at least one engine component via the 30 ... * • 1 . , u j: . c 4 , 

t _ i .^ & with a computer implemented embodiment of the present 

substantially consistent interface. invention* 

In accordance with another embodiment of the invention, m „ * .„ „ , . , , 

an image viewer process views at least one document image f illustrates a block diagram of the internal hard- 
including an electronic document image, and performs ware of the computer of FIG. 14; 

viewing operations to the electronic document image. The 35 FIG. 16 is a block diagram of the internal hardware of the 

process includes the step of selecting, by the user, one of a computer of FIG. 15 in accordance with a second embodi- 

plurality of image viewing perspectives. Each of the plural- ment; 

ity of image viewing perspectives provide the user the FIG. 17 is an illustration of an exemplary memory 

capability of viewing the document image in accordance medium which can be used with disk drives illustrated in 

with a different predefined user perspective. The process 40 FIGS. 14-16; 

also includes the steps of selecting, by the user, using the FIG. 18 is an illustration of another embodiment of the 

image viewer process the document image to be viewed, and component factory migrating the original "CMevel API 

retrieving, by the image viewer process, the document from its original state into the generic interface defined by 

image. The process also includes the step of displaying, by the topmost layer; 

the image viewer process, the selected document image in 45 mQ 19 is an illustration of a distributed environment or 

accordance with an image viewing perspective selected by architecture for manually and/or automatically generating 

the user. and/or using reusable software components for client server 

In accordance with another embodiment of the invention, ana y 0 r intranet operating environments; 

a computer readable tangible medium is provided that stores FIG 20 fe a delafled muslration of the distributed envi- 

the process thereon for execution by the computer. 50 Qf for maQuaU and/or automatica lly 

In accordance with another embodiment of the invention, generat ing and/or using reusable software components far 

a computer readable tangible mechum is provided that stores client and/or intranet {in envkonmcQ{s; 

an object thereon, for execution by the computer. „ . M1 _ . c , t , 

m. J 4 , iL 4 . \ j * . . . . FIG. 21 is an illustration of a distributed environment or 

These together with other objects and advantages which . . « „ 4 tl 

.... z *i . j *u j * -1 c « architecture for manually and/or automatically generating 

will be subsequently apparent, reside in the details 01 55 . c * f 

. t . - .. . . , ... and/or using reusable software components for network 

construction and operation as more fully herein described . f , . _ r 

j 1 • j **u c u • u a ♦ \u ~ • environments, such as the Internet: 

and claimed, with reference being had to the accompanying . ' . ' . . 

drawings forming a part hereof wherein like numerals refer ™ G 22 15 a Retailed ^lustration of the distributed enyi- 

to like elements throughout. ronment or architecture for manually and/or automatically 

60 generating and/or using reusable software components in the 

BRIEF DESCRIPTION OF THE DRAWINGS i ntC rnet environment; 

FIG. 1 is an illustration of the placement and/or use of the FIGS. 23A-23C are illustrations of the image viewer user 

computer architecture and/or method of the present inven- interface and/or functionality associated therewith in accor- 

tion; dance with the present invention; 

FIG. 2 is an illustration of the component factory migrat- 65 FIG. 24 is an illustration of a stand-alone and/or distrib- 

ing the original "C"- level API from its original state into the uted environment or architecture for image viewer in client 

generic interface defined by the topmost layer; server and/or intranet operating environments; 
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FIG. 25 is a detailed illustration of a stand-alone and/or systems using the technology. While there are millions of 

distributed environment or architecture for image viewer in Intranet developers and power-PC users who are capable of 

client server and/or intranet operating environments; assembling component-based systems, I have determined 

FIG. 26 is an illustration of a stand-alone and/or distrib- < hat ***** few ," C " Programmers (estimated at 

uted environment or architecture for image viewer in net- 5 le ¥j * an 10 ^>°^ "*» ca ? le f ™ f d Wj"***" 

work environments, such as the Internet; tnd 7' h 'T "f" C . 'w " * *f refore 

. . . desirable to develop software tools for automaticaDy gen- 

FIG. 27 is a detailed illustration of a stand-alone and/or erating reusable software components from core software 

distributed environment or architecture for image viewer in technologies thus making these software technologies avail- 

the Internet environment. able to a much larger user base. 

Since I have determined that there is no structure or 

NOTATION AND NOMENCLATURE format f or implementing "C'-level API's, the ability to 

The detailed descriptions which follow may be presented automatically transform a unique API into a standard com- 

, j ■ * j * ponent would seem impossible since that would take a 

in terms of program procures executed on a computer or * ^ J elli To date , me only way , l 

network of computers. These procedural descriptions and 15 am J iQ ^ a c * cnt out of an existing API is 

representations are the means used by those skilled in the art to haye ^ existin ^ er m mc ficld do me * ork for 

to most effectively convey the substance of their work to each ^ H umans can intelHgently analyze an API and 

others skilled in the art. create a component based on intelligent decisions tempered 

A procedure is here, and generally, conceived to be a by experience. The challenge of creating a component 

self-consistent sequence of steps leading to a desired result. 20 factory is the challenge of partially or substantially recreat- 

These steps are those requiring physical manipulations of ing the component design and formulating effective imple- 

physical quantities. Usually, though not necessarily, these mentation decisions. 

quantities take the form of electrical or magnetic signals One would expect the translating a "C"-level API from its 
capable of being stored, transferred, combined, compared native state into a component would require human-level 
and otherwise manipulated. It proves convenient at times, 25 intelligence. This is mainly because "C-level APIs have 
principally for reasons of common usage, to refer to these virtually no constraints as to how they can be implemented, 
signals as bits, values, elements, symbols, characters, terms, means that there are an infinity variations of APIs, 
numbers, or the like. It should be noted, however, that all of which OQl y te managed by human-level intelligence, 
these and similar terms are to be associated with the appro- ^ ? oint » truc > 1 ha ? c determined that the appro- 
priate physical quantities and are merely convenient labels 30 pnajc solution starts at the other side of the equation, which 

i * j * j.l is the component itself, 

applied to these quantities. y 

, „ . c fl r My solution starts out with a definition of a component 

Further, the manipulations performed are often referred to ^ caD sustain ^ feature/function requirements of any 
in terms, such as adding or comparing, which are commonly ^ olhcr words , the interface of a generic component 
associated with mental operations performed by a human can ^ defined such that the features and functions of 
operator. No such capability of a human operator is 35 virtually any API can be re-implemented within its bounds, 
necessary, or desirable in most cases, in any of the opera- The two known end-points are the "C"-level API that started 
tions described herein which form part of the present inven- with, and the component interface that represents any set of 
tion; the operations are machine operations. Useful features/functions on the other side, 
machines for performing the operation of the present inven- I have also determined that one solution for creating a 
tion include general purpose digital computers or similar 40 computer architecture and process for implementing a coin- 
devices, ponent factory is to create a well-defined multi-tiered sys- 

The present invention also relates to apparatus for per- tems architecture for a component and to automate, substan- 
forming these operations. This apparatus may be specially automate, or manually expedite from its native state 
constructed for the required purpose or it may comprise a ac *™!& me vanous tiers of the systems architecture result- 
general purpose computer as selectively activated or recon- 45 m S m * standardized or substantially standardized cornpo- 
2 , ,T . , . . nenL Advantageously, this solution is not based on making 
figured by a computer program stored in the computer. The " i i • . ,, ■ TZ Y . , , 4 6 
. \ , J ; ♦ . . u *i i • j . human-level intelligent decisions on how to translate a 
procedures presented herein are not inherently related to a , CMcvel ^ mt0 a component. Rather, by starting with a 
particular computer or other apparatus. Vanous general well _ de fined systems architecture that is multi-tiered, a 
purpose machines may be used with programs written in 5Q series of incremental steps that migrates a C-level API from 
accordance with the teachings herein, or it may prove more one ticr withm thc systems architecture to the next may be 
convenient to construct more specialized apparatus to per- performed, and which are facilitated using the architecture 
form the required method steps. The required structure for a and/or process described herein. 

variety of these machines will appear from the description Advantageously, each incremental step is not a major one, 

given* 5S but in sequence the entire series of steps will result in a 

usable component. Since each step of migration is not a 

BEST MODE FOR CARRYING OUT THE ma j or QQ ^ me chances of automating these steps is signifi- 

INVENTION cantly higher ^ me likelihood of being able to create the 

The purpose of the computer architecture and process component factory becomes more feasible, 

described herein is to create a component factory that can 60 Tne fundamental building blocks of the computer archi- 

automatically generate reusable software components from tecture and process are twofold: 

sophisticated core software technologies. Many, if not most, 1) To define a systems architecture that describes in detail 

core software technologies, such as OCR (Optical Character how to implement a component from a C-level API 

Recognition) or barcode recognition, are designed and 2) To create a component factory by automating, substan- 

implemented using a "C-language API (Application Pro- 65 tially automating, or manually expediting the migration 

gram Interface). The technology is often complex, requiring of a C-level API from one tier within the architecture to 

months of trial-and-error to correctly develop application the next. 
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The building blocks are the keys or important to actually Advantageously, the method described herein does not 

making the component factory feasible. base the component factory on making human-level intelli- 

Significantly, the computer architecture and processes gent decisions on how to translate a "C-level API into a 

described herein have application to the Intranet and docu- component. Rather, by creating a well-defined architecture 

ment market marketplace. Corporations are embracing inter- 5 described below that is multi-tiered, the method is a series 

net computing technologies to create enterprise-level Intra- of mcre mental steps that need to be taken to migrate the 

nets and Extranets. Using standard browser technologies, "C'-level API from one tier within the architecture to the 

corporations and government entities are rapidly adopting next , n mis each step is not a major onej 

the internet computing model and are developing enterprise but m Qce the eQtire ^ of st ^ ^ ^ a 

applications by assembling standard Microsoft specified com ^ 

Active X components. These are not "C" programmers; 0 . ' 4 - . . t , 

rather they are Epical power PC users. FurtherTvailability u Since P each ste P of mi 1 f atl0n 15 aot . a W 0 ^' * he 

of reusable components would only fuel this development. ch f <* s , f ° r ™ atm S thcscsteps is significantly higher 

The general outline for creating a component factory is and the ^hhood I of being able to create the component 

described below in detail. It is important to note that factor y Monies feasible. This approach is in fact what 

automatically, substantially automatically, or manually 15 makes thc . method cost-effective, since the alternative 

building a component is neither obvious nor guaranteed. As approach, i.e., computer-generated human-level decision 

will be described below in detail, automating or substan- making, is currently unavailable and would require much 

tialiy automating the building of a component consists of effort, if at all possible, to replace humans in any realistic 

automating individual steps that comprise the component decision-making process. 

architecture. However, in today's application environment, 20 With a fixed architecture that can be used to implement a 

any amount of automation will dramatically increase the "C-level API as a component (using a programmer), that 

efficiencies of building a component same architecture can be used as the basis for the component 

The computer architecture is designed for managing a factory model. In order to make the component factory, each 

diverse set of independent core technologies ("engines") step of the architecture needs to be designed to facilitate 

using a single consistent framework. The architecture bal- 25 automation or manually expedited. In other words, I have 

ances two seemingly opposing requirements: the need to determined that automating/expediting the process of taking 

provide a single consistent interface to many different the original "C'-level API and migrating it to a Level 1 

engines with the ability to access the unique features of each layer, and then a Level 1 to a Level 2, and then a Level 2 to 

engine. a Level 3 layer, and so on, the component has been imple- 

The benefit of the architecture is that it enables a company 30 mented automatically, or more efficiently manually. The 

to rapidly "wrap" a sophisticated technology so that other component factory is therefore a sum of the ability to 

high-level developers can easily learn and implement the automate migrating the u C-level API from one layer to the 

core technology. The computer architecture is therefore a next within a well-defined architecture for implementing 

middleware or enabling technology, as illustrated in FIG. 1. components. 

As illustrated in FIG. 1, computer architecture 2, 35 As illustrated in FIG. 2, the component factory 10 

described below in detail, is a middle layer between high migrates the original "C-level API 12 from its original state 

level developer programs 4 (such as C-level APIs, or other into the generic interface 8 defined by the topmost layer. The 

programs having similar characteristics) and are technology/ first feature that can be demonstrated is that there is a 

component engines 6 (such as OCR, bar code recognition, topmost layer 8 that can define a component interface that 

and other components having similar characteristics). 40 can represent the features/functions of most core technolo- 

Another benefit of the architecture is that it provides a gies. The component factory 10 migrates the "C'-level API 

high-level specification for a consistent interface to any core 12 to the topmost level 8. Doing this in one large step would 

technology. Once a high-level developer learns the interface be impossible since the "C'-level API has a near-infinite 

described herein for one engine, that knowledge is easily variety of styles. However, the architecture advantageously 

transferable to other engines that are implemented using the 45 has enough well-defined and well -structured layers for 

architecture. For example, once a high-level developer implementing the topmost component interface, for creating 

leams to use the computer architecture for OCR (Optical the component factory. 

Character Recognition), using the computer architecture for A simplified overview of the architecture is illustrated in 

other engines, such as barcode recognition or forms FIG. 3. In FIG. 3, the component interface 8 sits on top of 

processing, is trivial. 50 an Object Manager 14 that communicates with individual 

In summary, the architecture and process described herein objects e.g., 16, 18, 20. These objects 16, 18, 20 represent 

is at once a framework for rapidly wrapping sophisticated specific core technologies that are represented as "C'-level 

technologies into high-level components, as well as a frame- APIs. The design of Objectl, Object2, . . . ObjectN is 

work for high-level developers to communicate with a illustrated in FIG. 4. 

diverse set of engines. The creating of a component factory 55 A component factory can be created by automating the 

is based on the fact that the architecture defines a clear path process of migrating the original "C"-level API 12 from its 

for "wrapping" any C-level API into a component using original state to the Layer 1 — Engine Management tier 26, 

simple structures and many rote steps. This process is and then from the state to Layer 2 Engine configuration tier 

currently being done in an inefficient manner by a program- 24, and so on up the Engine Functions layer 22. These layers 

mer in the field. 60 will be further described below. 

The method described herein for creating a component The computer architecture is implemented, for example, 

factory creates a well-defined multi-tiered architecture for a as a standard COM component, as an ActiveX control; the 

component and automates, substantially automates, or specifications designed by Microsoft, published in the tech- 

manually expedites (hereinafter "automates") the process of nical literature, and incorporated herein by reference, 

migrating a "C'-API from its native state through the 65 ActiveX control (COM) support is currently available within 

various tiers of the architecture resulting in a standardized any Microsoft 32-bit Windows operating environment, 

component. ActiveX controls are supported by all OLE-based 
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applications, including all of Microsoft's end-user products numerous sophisticated technologies in a plug-and-play 

(e.g., Microsoft Office, Word, Access, Powerpoint, Access), environment. In order to facilitate the discussion of the 

the main Internet Browsers (Microsoft's Internet Explorer architecture itself it is best to start with the architecture of 

and Netscape's Navigator — the latter with an add-in product the engine object component and then describe the Object 

and by 4Q97 directly), most other name-brand end-user 5 Manager. Since the Object Manager is directly dependent on 

Windows products (e.g., Lotus Notes), and all major devel- the engine object components, an understanding of the latter 

opment environments (e.g., Microsoft Visual Basic and will assist in the description of the former. 

Visual C++, Delphi, Borland C++, Power Builder). By Engine Object Component— 16, 18, 20 

implementing the architecture as, for example, an ActiveX The purpose of the engine object is to wrap a specific 

control, complex technologies can be programmed by vir- 10 engine using a series of layers that convert the engine's 

tually any Windows or Intranet user or developer. Of course, unique interface into a COM interface that is, for example, 

other component specifications may also be used. specified by the architecture. The architecture not only 

Although the architecture has been implemented as a consistent COM interface for implementing an 

COM-based technology with C++ as the language of choice, lt ^? ^ J? r P ^°™ 

the architecture can be implemented in many other lan- 15 mc "f^vel API. Once the COM ^interface 

, , \ j J. , m . j ... ' / 13 or the engine object component is implemented, the Object 

guages (e.g. Java) and distributed architectures (e.g. w • , K 4 . r ■ * 

%r\nr>A\ Manager understands and can therefore communicate with 

CUKrJAJ. *j 

Every engine, such as a text retrieval or an OCR (Optical " Eacfa en ^ nc co nt Q0JI ^ S ^ for cxampkf three 

Character RecogmUon) engine, has a unique interface. This layers mat are designed t0 migrate the original API of the 

interface is generally a "C"-level API (Application Program 20 engilie to a consistent COM interface. As illustrated in FIG. 

Interface). In most cases, the learning curve for understand- 6 me ob j ec( Manager 14 communicates with the topmost 

ing and integrating a new engine can be a one man-month to layer 22 0 f tne object component 16, 18, 20 which is the 

several man-years and generally requires highly experienced defined interface of object component. 

"C" programmers. The purpose of the architecture is to E ach layer is described below in two parts. The first part 

define a clear infrastructure within which any core can be 25 ^ the prescribed COM interface for communicating with the 

rapidly "wrapped" so that users and developers can have enginc oh ^ x component. The second part describes a 

easy access to these core technologies. specific path for automating building the layer. By providing 

In addition to defining the infrastructure for engines to be an outline for automating building each layer, the overall 

accessible to typical users, the architecture also defines how engine ob j ect 00^^ can be automatically, substantially 

to migrate an engine from its native state to the prescribed 30 automatically or manually expedited and generated, 

interface. In other words, the architecture goes beyond Layer 1— Engine Management 26 

simply denning the framework for wrapping engines, it also ^ fim Iayer in the object componea t architecture is 

defines the specific steps for wrapping these engines. designed to deal with the fundamental features of an engine. 

The architecture consists of a hierarchical series of layers ^ mc iudes the ability to load and unload the standard or 

that take any "CMevel API from its unique state to one that 35 commercially available via, for example, MicroSoft 

is standard and consistent. The result is a single, highly- Corporation, engine Dynamic Link Libraries (DLLs) into 

integrated object component that contains and manages any mernory> ^ we U as the ability to consistently deal with 

type of engine that can be programmed regardless of the errors This ^ the most fundamental layer because it is the 

nature and subject of the core technology. The architecture essential "wrapper" layer of an engine. Once this layer is 

therefore not only defines the goal (e.g., the object compo- ^ complete all interaction with the underlying engine is fil- 

nent interface) but also the means of implementing that goal tered through this layer. Additional important engine man- 

for any type of engine. agement functions include dynamically accessing a function 

The architecture is comprised of two major parts as caUof an engme, and initiaUzmgengme settings. All of these 
illustrated in FIG. 5: the Object Manager 14, and the engine management functions are optionally and benefi- 
individual object components 16, 18, 20. The Object Man- 45 ciaIly table driven to promote or facilitate access to, and 
ager 14 in FIG. 5 manages individual object components 16, implementation of, engine management functions. 
18, 20 illustrated as Object 1, Object 2, etc. The Object j specification is summarized in FIG. 7 that 
Manager 14 communicates with the individual object com- describes the IEngineManagement COM interface. The op- 
ponents 16, 18, 20 using a consistent COM interface. pose of tne IEngineManagement interface is to transparendy 

Each object component implements the feature set of an 50 load ^ unload an engine to and from memory. I have 

individual engine by mapping a consistent COM interface to determined that this is often the core feature that is incor- 

the "C"-Level API interface of the individual engine that it rectly implemented and a cause for hard-to-find bugs- This 

supports. In this way the Object Manager can consistently layer may be generated manually by a developer who is 

communicate with each engine, using the engine's object familiar with the architecture as outlined herein in an 

component. Because the COM interface of each object 55 expedited manner or automatically as described below in 

component is consistent, the Object Manager can interface detail. 

with every underlying engine the same way. Laycr 1 ^n ^ prcc isely defined in generic terms, and is 

The features of the architecture include: therefore the simplest layer to likely be automatically, sub- 

1) definition of consistent COM interfaces for individual stantially automatically, or easily manually generated. A 
object components that represent diverse technologies; 60 samp le or example of actual code that can be used to 

2) a prescribed process for migrating any engine to the implement this layer is described below. As long the process 
defined consistent COM interface; and/or and/or code for implementing Layer 1 can be generically 

3) a predefined Object Manager that automatically man- defined, that is engine and technology independent, then the 
ages the individual object components. process of generating the generic code for each new engine 

When implemented, for example, as an ActiveX control, 65 is expedited either manually or automatically, 

the architecture also yields an umbrella control that can be The premise for automating any level is to start with as 

used by a high-level programmer to program and manage few pieces of information as possible, For the Engine 
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Management layer I have assumed that nothing more than 
the set of DLLs that implement the engine functionality are 
known. Given this information, I have determined that I will 
need to implement: 

Loading and unloading the engine from memory 

Adding error management 

We can start, in this example, with a model C++ header 
file that defines the Engine Management layer and investi- 
gate how this code can be implemented generically. As 
mentioned earlier, if the code to implement this layer can be 
defined generically then it can be easily generated, for 
example, manually, and/or automatically for any engine. 
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within a DLL, a simple loop may be used. The hLib module 
is derived from the DLL name, which, as mentioned at the 
start, is the one piece of information we are given. 

What is more complex is to define a generic implemen- 
tation of the engine object version of the original function. 
This may be described in code as follows: 



BOOL SomeFunction (arguments) 
10 ASSERT (arguments) 

Error VkriabIe-_SomeFunction (arguments); 
return Process ErrorO; 



class SomeEngiflcObjcct 
{ 

//Wrapper Functions 
private: 

FAR PROC_So me Function; 

BOOL SomeFunctionO; 

//EngineManagcnient 
protected: 

BOOL GetProcAddress (HINSTANCE, FARPROC&, LPCTSTR); 
BOOL GetProcAddrcssesO; 
BOOL ProcessErrorO; 
public: 

BOOLActivateEnginc (BOOL Activate); 
BOOL IsEngineActivatedO; 

}; 



The lEngineManagement interface is implemented in the 
C++ class as the public methods: ActivateEngine( ) and 
IsEngineActivated( ). 

The first step of implementing the Engine Management 
layer 20 is to wrap each original engine function within a 
class-defined function that represents the original. For 
example, if there is an original function called 
Somefunction( ), then the engine object should have a 
corresponding Somefunction( ) method. The engine object 
version can then add standard engine and error management 
code so that any layers above have automatic error detection, 
correction, and reporting. 

An example of generic code that maps an original func- 
tion call to the original function is as follows: 



BOOL GetProcAddress (HINSTANCE hLib, FARPROC&Proc, 

LPCTSTR ProcName) 

{ 

Proc-::GetProcAddress (hLib, ProcName) 

if (IProc) 

{ 

SetlMAGrnEError (LOADENGINEFUNCTIONSERROR, 
ProcName); 

return FALSE; 

} 

return TRUE; 



Given the original function name, the GetProcAddress 
can map the original function to one that is defined by the 
engine object. Using the engine object C++ header file 
described above, the Somefunction( ) method is mapped to 
the original engine function using the following line of code: 

(GetProcAddress(hLib, SomeFunction, "SomeFunction" ); 

To map all the function calls within the original engine 
DLLs just requires cycling through each function call and 
mapping it to the engine object counterpart. Since Windows 
contains facilities that enables access to all the functions 



The engine object version of the original function passes 
the function call to the original one after completing a series 
of assertion tests, and is followed by a series of error 
detection tests. In this way the original engine function is 
"wrapped" by the engine object to manage error detection 
and correction. 

The process of loading an engine can likewise be imple- 
mented generically. 



The LoadDLLs function is a generic implementation of a 
function that loops through the names of DLLs that are 

provided (in the form of the m Modules variable), and 

cycles through each one loading it into memory using the 
Windows LoadLibrary( ) function. A similar engine object 
function can be implemented to remove these DLLs from 
memory. 

The present invention further divides the engine manage- 
ment layer into three functions, as illustrated in FIG. 8. The 
first function is loading and unloading 124 of the core or 
engine technology. The second function for the engine 
management layer 26 is dynamically linking procedures or 
function calls, or hooking the desired engine functionality 
into the procedures of the core technology 126, including, 
for example, initializing and setting up engine settings. The 
third function is initializing the engine itself 128, which is 
essentially engine management. Once these three functions 
are performed in level 1, anything in the core technology is 
accessible. 
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BOOLLoadDLLsO 
{ 

BOOLbReturn=TRUE; 
HINSTANCEt_hLib ; 

CStringt ModulcNamc; 

POSinONpos; 

pos-m_Modules ■ GetStartPositionO; 
30 if (pos=NULL) 
{ 

SetEMAGinEError (NOMODULESDEFTNED); 
return FALSE; 

} 

while (pos&&bReturn) 
35 { 

m_Modules ■ GetNextAssoc (pos, t ModuleName, t hLib); 
if (t_hLib!-NULL) 
continue; 

l_hIib=»::LoadLibrary (L_ModuleName); 
if (t_hLib-NULL) 
{ 

SetTMAGinEError (CANTLO AD MODULE, 
t_Modu]eName); 
FrccDLLsO; 
bReturo-FALSE; 
break; 

} 

m__Modules ■ Set At (c_Modu!eName, t_hLib); 
} 

re turrib Return; 
} 
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Advantageously, the present invention utilizes tables to interface. The purpose of the IEngineConfiguration interface 

drive each of these three functions described above, and as is to provide the ability to set and get the settings of any 

illustrated in FIG. 9. Each of the tables of files, for example engine uniformly. While the Engine Management layer can 

tables 130, 136, 140, are filled in with the appropriate data load and unload engines transparently, this layer configures 

or information. I have discovered that if the above three 5 engines to operate as required by the user or developer, 

functions are set up or implemented using tables, that the FIG. 11 is another exemplary table illustrating the engine 

core technology may be effectively and efficiently described. configuration specification. Examples include a set setting 

That is, the use of tables is a very effective and simple function 144, a get setting function 146, a load setting 148, 

method of describing an engine for use in engine a save setting 150, an is setting valid function 152, a default 

management, engine loading/unloading and engine proce- 10 setting 154, and a prompt setting 156. 

dure linking. For example, it is similar to indicating or The get setting 146 and set setting 144 functions retrieve 

providing the raw data of that engine, the list of the engine foe value of a particular engine setting, or assign a value to 

functions, and the list of the engine dynamic link libraries a particular engine setting, respectively. Each one of the get 

(DLLs) for engine management. setting and set setting functions includes or comprises a 

The files or tables contain the logic or executable of the is table of the settings. The load setting 148 and save setting 

engine. Accordingly, all that is needed is a list of the engine 150 functions do the similar function as the get setting and 

functions 132, a list of the file of the engine executable code set setting functions, but in persistence. Persistence is 

or DLLs 138, and a list of the engine settings 142. Using the defined « writing values to the disk, for example hard disk, 

tables with the above information, the engine may be compact disk, and the like, and retrieves the values from the 

automatically loaded and unloaded, initialized, and/or 20 disk. So as where the get setting and set setting functions 

dynamically hooked into the necessary functions. assign a value and/or retrieves the value from local memory, 

Accordingly, the process of generating level 1 for engine &e load and set setting functions assign the value and 

management may advantageously be automated. The spe- retrieve the value of the setting from disk. The load and set 

cific algorithms used for the engine management layer are setting functions provide persistence when the computer 

described in Appendix A. 25 system is close down, such that when the computer system 

In summary, for the Engine Management layer the fol- will return to the last setting when it is subsequently 

lowing pieces may be automated, substantially automated, reopened. 

and/or manually expedited. ^ ^fault setting function 154 provides the most favor- 
Loading and unloading the engine DLLs (provided into a u ble value ft™*™ setting. Thus, if no setting is .selected, 
and out of memory the system will automaUcally select default settings. The 

prompt setting function 156 is what displays to the user all 

Mapping original functions to engine object counterparts mc various settings. The specific algorithms used to imple- 

Adding general error detection and correction men t the engine configuration layer are included in Appen- 

Determining and matching arguments and return values dix B. 

for mapping the original functions to their engine 35 Advantageously, the present invention generates the skel- 

object counterparts. In order to add assertion and error etal structure of each table automatically. In addition, since 

detection and correction, the original function must be there is a table of settings, the skeletal structure not only 

wrapped and called from within the engine object generates these functions, but also fills in the settings that 

version of the original function. need to be assigned. Thus, the engine configuration function 

Managing error feedback. All APIs have their own way of 40 provides the feature of having a pre-populated set of options 

providing error feedback. Since one of the goals of the which require particular values to be assigned to table 

Engine Management layer is to generically manage entries. 

error detection, correction, and feedback, it must Although this architecture advantageously makes it 

handle all errors identically. However, APIs have simple for a human to migrate the configuration of an engine 

numerous and incompatible methods in this case. I 45 appear into two simple and universally applicable interface 

have determined that most APIs follow one of several PoinXs, doing so automatically requires additional steps. The 

distinct mechanisms for providing error feedback. By two steps to automating this approach are, for example, as 

creating specific classes of APIs, the process of gener- follows: 

ating Layer 1 engine management may be expedited, Determine the configuration methods used by various 

manually and/or automatically. 50 APIs for configuring the core technology; 

Layer 2 — Engine Configuration 24 Detect the variations for configuring an engine and auto- 

The second layer 24 in the object component architecture mating each one separately, 

is designed to deal with configuring an engine. This includes As with Layer 1 — Engine Management, there exists a 

the ability to set any variety of features that are generally finite set of general variations used by developers of core 

associated with the functioning of an engine. The architec- 55 technologies to configure an engine. Although Layer 1 is 

hire is designed to meet the challenge of providing a uniform clearly more generic in nature, advantageously, Layer 2 also 

interface for dealing with generally any or most engine has considerable consistency, 

settings. Layer 3— Engine Functionality 22 

The engine configuration layer 24 includes a series of The third layer 22 in the object component architecture is 

prefabricated functions that map out the settings stored in 60 designed to deal with accessing the actual functionality of 

the table to the appropriate engine configuration parameters. the core engine. For example, for an OCR engine this would 

Accordingly, all that is needed is to fill in the values for the be to OCR an image or a document. For a text retrieval 

table associated with engine configuration. Thus, the engine engine this would be to initiate and retrieve results of a text 

object may advantageously come pre-packaged with prede- search. 

termined tables populated with predetermined values. 65 An exemplary Layer 3 specification can be summarized in 

The Layer 2 specification can be summarized in FIG. 10 FIG. 12 that describes the IEngineFunction COM interface, 

that describes an exemplary IEngineConfiguration COM The purpose of the IEngineFunction interface is to provide 
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the ability to initiate any function supported by an engine. because the technologies are only available as "C'-level 

The simple IEngineFunction interface is capable of manag- APIs. Without the core competency of creating components 

ing an infinite variation of functions. out of these core technologies they are limiting their mar- 

The third layer may advantageously be further divided ketability and opportunity for international distribution, 

into many sub-layers that more discretely define the steps 5 with the proposed component factory users and vendors 

necessary to execute a function within an API. Since the caQ rapidly create components from their original core 

designer of an API has infinite variety of possible ways of technology and increase their marketability, 

implementing a function, creating a tiered architecture to competitiveness, and ultimately their sales, 

manage this layer is useful . . . Further, there are numerous core technologies, such as 

^exemplary tiered a^ text-retrieval and ICR (Intelligent Character Recognition), 

is illustrated in FIG. 13, As illustrated in FIG. 13, the engine tU . . . > . 6 ^ A A . & .. , /' 

function or engine processing layer includes fouV elemell *™ tmplemented and are only available 

THe engine function^ layer 22 includes a series of predefined f -level APIs. Many, if not most core technologies are 

functions to perform in the perform element 158. For firet released exclusively as "C -level APIs. While there are 

example, for optical character recognition (OCR), the integrators and corporations who have the team of technolo- 

present invention uses a set of predefined functions. 15 gists who can integrate these "C"-level APIs m-house, most 

Alternatively, for scanning, the present invention includes a companies are looking for component versions that can be 

separate set of predefined functions. implemented at a much higher level. Therefore, many of the 

Accordingly, there are a series of actions that are per- core technologies that are only available in a "C'-level API 

formed by the engine function layer on a given engine, such are not ^ t0 theu * inaccessible interface. The 

as an OCR engine, a scanning engine, a printing engine and 20 oeaefit of tbe component factory is that it can rapidly make 

the like. The engine function layer is designed not to available core technologies implemented as "C APIs that 

generally go directly to a specific engine. Rather, the engine would otherwise be underutilized or dormant m research 

function layer 22 will generally interface with the engine labs °y converting them to high-level components that can 

management layer 26 and/or the engine configuration layer be used b y millions of power-PC users. 

24 as needed 25 with ±c advent of ^ World Wide WeD O^ 3 ) ±is 

For example, in the course of performing an action and/or opportunity has increased exponentially. The WEB is now 
function, the engine function layer interfaces with the engine Dome to a vast number of WEB authors with minimal formal 
configuration layer to possibly modify settings. For an OCR trwiag who can implement HTML pages and build web 
engine, the engine function layer fills out a table of OCR sites - 0ne of me fundamental technologies for extending the 
documents as one action that could take place. OCR image 30 capability of the WEB from simple page viewing to inter- 
is another action active and sophisticated applications is components. A com- 

The get function results 160 gets the results of the ponent extends the capability of HTML by enabling a WEB 

function stored in a register. The clear function 162 clears all author lo add ^ technology as a pre-packaged technology, 

the registers that contain all the results, in this case its Since components are fundamental to the growth and usabil- 

memory. The feedback event or function 164 provides 35 ity of the WEB, having a component factor that can translate 

continuous feedback, depending on what action takes place. "C'-level toolkits mto components that are then usable 

For example, if an OCR action is being performed, the ^ B sites ?V cns a vast and ncw worldwide market 

feedback function provides the percentage of completion of to these technologies. 

the OCR process. The specific algorithms used to implement 14 is an illustration of a main central processing umt 

the engine function layer are included in Appendix C. 40 for implementing the computer processing in accordance 

The automation of this layer is accomplished by the ^ a computer implemented embodiment of the present 

following functions- invention. The procedures described above may be pre- 

Determine the execution of methods used by various APIs terms of P ro S ram Procedures executed on, for 

for executing a given function; example a computer or network of computers. 

. * • . . * * . . 1t . 4 . , . t , t , . 45 viewed externally in FIG. 14, a computer system desig- 

Divide this layer mto a multi-tiered layer that further , , , - J . , A ' \ . J . ~ 4 

facilitates automation* nated by reference numeral 40 has a central processing umt 
. . r \ , , t ,42 having disk drives 44 and 46. Disk drive indications 44 

Detect the variations of the sub-layeis and automate each and ^ m mereIy symboJic of fl number rf ^ 

one separately. which might be accommodated by the computer system. 

Although this layer has many more variations than Layer 50 Typica j ly would include a floppy disk drive such as 44, 

2, 1 have : determined that there is a general set of vanaUons a harf ^ ^ (n0 , shown externall } and a CD R0 M 

used by developers of APIs to implement core functionality. b ^ ^ ^ numbef ^ q{ dlives 

Thus, the benefit of the component factory us that it can ^ ^ differem mer ^te. drives 

transform core software technologies that arc currently 44 arjd 46 are in fact optional, and for space considerations, 

available in C -level APIs to a limited audience mto J5 easfl ^ omitted &om tbe mm m ^ m 

components that have a much greater audience. conjunction wilh the production process/apparatus described 

There are a variety of "C'Mevel APIs that cover the beo : m * * * v 

following categories of functionality that can be better The computer also has an optional display 48 upon which 

served m the market as ActiveX controls or other component mformation is displayed. In some situations, a keyboard 50 

and used in conjunction with the archrtecture and methods 6Q and „ fflouse 52 may be prwided ^ mput (0 

described herein. interface with the central processing unit 42. Then again, for 

Text Retrieval enhanced portability, the keyboard 50 may be either a 

Data Extraction limited function keyboard or omitted in its entirety. In 

Workflow addition, mouse 52 may be a touch pad control device, or a 

Storage Management 65 track ball device, or even omitted in its entirety as well. In 

Each of these categories has several vendors with prod- addition, the computer system also optionally includes at 

ucts that currently service the market in a limited way least one infrared transmitter 76 and/or infrared receiver 78 
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for either transmitting and/or receiving infrared signals, as Conventional processing system architecture is more fully 

described below. discussed in Computer Organization and Architecture, by 

FIG. 15 illustrates a block diagram of the internal hard- William Stallings, MacMillam Publishing Co. (3rd ed. 
ware of the computer of FIG. 14. Abus 56 serves as the main 1993); conventional processing system network design is 
information highway interconnecting the other components 5 more fully discussed in Data Network Design, by Darren L. 
of the computer. CPU 58 is the central processing unit of the Spohn, McGraw-Hill, Inc. (1993), and conventional data 
system, performing calculations and logic operations communications is more fully discussed in Data Commu- 
required to execute a program. Read only memory (ROM) nications Principles, by R. D. Gitlin, J. F. Hayes and S. B. 
60 and random access memory (RAM) 62 constitute the Weinstain, Plenum Press (1992) and in The Irwin Handbook 
main memory of the computer. Disk controller 64 interfaces 10 of Telecommunications, by James Harry Green, Irwin Pro- 
one or more disk drives to the system bus 56. These disk fessional Publishing (2nd ed. 1992). Each of the foregoing 
drives may be floppy disk drives such as 70, or CD ROM or publications is incorporated herein by reference. 
DVD (digital video disks) drive such as 66, or internal or Alternatively, the hardware configuration may be arranged 
external hard drives 68. As indicated previously, these according to the multiple instruction multiple data (MIMD) 
various disk drives and disk controllers are optional devices. 15 multiprocessor format for additional computing efficiency. 

A display interface 72 interfaces display 48 and permits The details of this form of computer architecture are dis- 
information from the bus 56 to be displayed on the display closed in greater detail in, for example, U.S. Pat. No. 
48. Again as indicated, display 48 is also an optional 5,163,131; Boxer, A., Where Buses Cannot Go, IEEE 
accessory. For example, display 48 could be substituted or Spectrum, February 1995, pp. 41-45; and Barroso, L. A. et 
omitted. Communication with external devices, for example, 20 al, RPM: A Rapid Prototyping Engine for Multiprocessor 
the components of the apparatus described herein, occurs Systems, IEEE Computer February 1995, pp. 26-34, all of 
utilizing communication port 74. For example, optical fibers which are incorporated herein by reference, 
and/or electrical cables and/or conductors and/or optical In alternate preferred embodiments, the above-identified 
communication (e.g., infrared, and the like) and/or wireless processor, and in particular microprocessing circuit 58, may 
communication (e.g., radio frequency (RF)> and the like) can 25 be replaced by or combined with any other suitable process- 
be used as the transport medium between the external ing circuits, including programmable logic devices, such as 
devices and communication port 74. PALs (programmable array logic) and PLAs (programmable 

In addition to the standard components of the computer, logic arrays). DSPs (digital signal processors), FPGAs (field 

the computer also optionally includes at least one of infrared programmable gate arrays), ASICs (application specific inte- 

transmitter76 or infrared receiver 78. Infrared transmitter 76 30 grated circuits), VLSIs (very large scale integrated circuits) 

is utilized when the computer system is used in conjunction or the like. 

with one or more of the processing components/stations that FIG. 18 is an illustration of another embodiment of the 

transmits/receives data via infrared signal transmission. component factory migrating the original "C'-level API 

FIG. 16 is a block diagram of the internal hardware of the from its original state into the generic interface defined by 

computer of FIG. 14 in accordance with a second embodi- 35 the topmost layer. This powerful architecture goal is to 

ment. In FIG. 16, instead of utilizing an infrared transmitter supply easy access to all imaging functions that can be 

or infrared receiver, the computer system uses at least one of performed by any engine. 

a low power radio transmitter 80 and/or a low power radio The architecture according to this second embodiment, 

receiver 82. The low power radio transmitter 80 transmits groups C-level toolkits 100 into logical categories, such as 

the signal for reception by components of the production 40 scan, print, display, OCR, cleanup and so on. A single engine 

process, and receives signals from the components via the can span multiple categories (e.g., Kofax engine does view/ 

low power radio receiver 82. The low power radio trans- print/scan). This enables the architecture to deal with the 

mitter and/or receiver 80, 82 are standard devices in indus- multitude of engines available in a logical fashion, 

try. On top of these, a three-level C++ class (or object) 102 is 

FIG. 17 is an illustration of an exemplary memory 45 built for each engine. This object gives uniform access to the 

medium which can be used with disk drives illustrated in engine and to all its unique settings. The three levels do the 

FIGS. 14-16. Typically, memory media such as floppy disks, following: 

or a CD ROM, or a digital video disk will contain, for Level 1 of the C++ classes 112 is a protective wrapper for 

example, a multi-byte locale for a single byte language and each function call in the underlying engine. It traps all errors 

the program information for controlling the computer to 50 and provides error management and administration to pre- 

enable the computer to perform the functions described vent accidental GPFs or engine crashes, 

herein. Alternatively, ROM 60 and/or RAM 62 illustrated in Think of it as the "condom layer.*' While providing the 

FIGS. 15-16 can also be used to store the program infor- most direct access feasible to the underlying engine and all 

mation that is used to instruct the central processing unit 58 its capabilities, level 1 of the C++ class 112 also protects the 

to perform the operations associated with the production 55 user from the engine. It manages all engine loading and 

process. unloading, prevents multiple copies of an engine and calls 

Although processing system 40 is illustrated having a engines automatically as needed, 

single processor, a single hard disk drive and a single local The architecture also provides three levels of access: 1. 

memory, processing system 40 may suitably be equipped Use the default engine settings. Benefit: No learning up 

with any multitude or combination of processors or storage 60 front. Program knowing nothing other than "OCR gets text 

devices. Processing system 40 may, in point of fact, be out of there/* 2. Prepackage customized engine settings. Set 

replaced by, or combined with, any suitable processing it once for everyone who uses the program, every time they 

system operative in accordance with the principles of the use the program. 3. Modify engine settings at run-time. Let 

present invention, including sophisticated calculators,and the user choose the settings. 

hand-held, laptop/notebook, mini, mainframe and super 65 Level 2 of the C++ classes 114 bridges the low-level API 

computers, as well as processing system network combina- calls so they can be used by level 3 116 in standardized calls 

tions of the same, for each category. And it supplements the engine by pro- 



11/17/2003, EAST Version: 1.4.1 



US 6,185,590 Bl 

23 24 

viding additional functionality, such as safely loading and Microsoft Corporation. ActiveX is a protocol for component 

unloading engines. communication. The present invention also creates each of 

Level 3 of the C++ class 116 consists of a standardized set the object manager and the engine component layer as a 

of calls for all engines in each category. Programmers can separate ActiveX. That is, the object manager is its own 

access all the unique functions of each engine in a uniform 5 ActiveX control, and the engine object is its own ActiveX 

way. control. Thus, the engine object can now run independently 

Another associated C++ class, called a Visual Class 104, from the object manager. Accordingly, the engine object can 
adds a visual interpretation of each engine. This class operate without relying necessarily on the concurrent opera- 
manages all user interaction with each underlying engine. tion of the object manager. 

Like their lower-level counterparts, the Visual Class consists 10 The independent relationship between the engine object 

of three layers: and the object manager means also that the engine object 

Level 1 — 118 adds any dialogs or other pop-up window represents a discrete means of technology. For example, an 

capability that may be lacking in each engine. Examples: engine object can be an OCR technology. This provides 

Dialogs to customize the engine settings or, for a recognition several benefits. First, because the object manager layer is 

engine, the zone definition settings. 15 open, the manufacturer of the OCR technology can wrap 

Level 2 — 120 serves two functions: It bridges level 1 their own engine in the form of an engine object component, 

dialogs with the actual Windows window that represents the and the engine will automatically "plug into" or work with, 

control. It also handles all Windows-related error message the object manager. Thus, the engine object is provided high 

presentation. level access, making it accessible to many more parties, 

Level 3 — 122 manages anything else from the underlying 20 users, and the like. When the object manager interface is 

engine (such as annotations) that needs to appear on the designed to be open, any third party, such as an engine 

window. The Visual Class includes engine-specific Windows manufacturer, can create their own engine object component 

dialog boxes that let you customize which engine features that is compatible with the object manager, the manufacturer 

you want to use, as well as any other Windows representa- can do it. 

tion necessary for a toolkit. (For example, a compression 25 FIG. 19 is an illustration of a distributed environment or 

engine has to display the image — the visual class, not the architecture for manually and/or automatically generating 

engine, does the work.) and/or using reusable software components for client server 

The Object Manager layer 106, the first horizontal and/or intranet operating environments. A very significant 

umbrella, orchestrates the underlying objects. It translates point that is relevant to why the object manager and the 

service requests into a form that the engine objects can 30 engine object component are independent in the present 

understand. invention relates to providing a distributed environment for 

The Windows Manager 108 presents Windows messages using the present invention. Rather than communicate 

(move window, mouse/scrollbar/toolbox activity) to the within the same technology between the object manager and 

Object Manager. It is written using Microsoft's Foundation the engine object, the object manager and the engine object 

Class (MFC), which makes it easy to support OCXs. (The 35 component communicate with each other in binary mode, 

OCX is in fact an MFC class.) via, for example, standard distributed component object 

At the top, a visual interface 110 presents to the user a set module (DCOM) communication. As illustrated in FIG. 19, 
of visual calls and translates those calls into Windows object manager 14 communicates with engine object corn- 
messages. This layer comprises only 5% of the VBX code, ponent 16, 18, 20 via DCOM specification 166. Other types 
yet it permits the toolkit to appear as a VBX, OCX or other 40 of component communication may also be utilized that 
standard visual interface. provide the capability of a distributed component interac- 

Accordingly, the present invention provides two main tion. 
layers, the engine object component layer and the object Thus, the engine object component and the object man- 
manager layer. By creating these two main layers, the ager can leverage current protocols to not only communicate 
present invention allows third parties to create their own 45 on the same machine, but also on different machines such as 
engine object component layers so that the third party engine a client server and/or intranet and/or Internet environment, 
can be readily compatible and useable by the present inven- The object manager can be placed on one machine, and the 
tion. In addition, the present invention is accessible via the engine object component on another machine and have 
Internet. That is, the present invention is operable over the distributed processing, what is otherwise called thin client 
Internet using, for example, standard Internet protocols, 50 processing, distributed processing, wide area intranet pro- 
such as component object module (COM) communication cessing. 

protocol and distributed COM (DCOM) protocol. What this allows the present invention to do is to put the 

In addition, the present invention optionally combines object manager on the thin client, who would accept the 

three layers of functions including the visual interface, the request from the user, for example, to OCR something or to 

windows manager and the object manager into one layer 55 print something. The actual request is handled or processed 

called the object manager. Of course, this combination of by the engine object component which generally resides on 

layers is not meant to convey that only these specific layers the server. The engine object component contains the horse 

must be used, but rather, to be indicative of overall func- power, or the processing power to process the request, 

tionality generally required to implement or execute com- The engine object layer is generally located in the same or 

ponent engines. That is, one or more of the above functions 60 substantially same location as where the core technology or 

may be incorporated into the object manager layer. The engine itself is being stored. Alternatively, the engine object 

present invention also advantageously combines the visual layer and the engine may be optionally located in a distrib- 

classes and C++ classes into the engine object component to uted environment on different machines, servers, and the 

further standardize and/or provide access to the object like. 

manager for engine object components. 65 FIG. 20 is a detailed illustration of the distributed envi- 

The present invention optionally uses the standard ronment or architecture for manually and/or automatically 

ActiveX component control supplied, for example, by generating and/or using reusable software components for 



11/17/2003, EAST Version: 1.4.1 



US 6,15 

25 

client server and/or intranet operating environments. In FIG. 
20, client 170 includes object manager layer 172. Client 170 
executes the core technology 180, via accessing engine 
object layer 178 managed/stored on server 176, and com- 
municated via server 174. 

Client 182, located on the same server 176 as core 
technology 180 and engine object layer 178, may also be 
used to execute the core technology 180 via object manager 
layer 184. In this instance, the client 182 with the object 
manager layer 184 is located on the same server 176 as the 
engine object layer 178. In addition, since the present 
invention utilizes a communication protocol between 
components, for example, DCOM, that allows a client to 
also include both the engine object component layer and the 
object manager layer on the same machine 186, as well as 
the core technology. 

Further, since the object manager is formatted or con- 
structed of a client technology, the object manager can sit in 
a standard browser. This means that anyone that has an 
Internet browser, i.e., anyone that has access to the world 
wide web (WEB) can actually access the core engine tech- 
nology. Thus, by structuring the architecture of the present 
invention as described herein, users automatically become 
Internet, intranet and/or WEB enabled. 

The present invention also transforms the core technology 
from essentially client based technology into a client server 
and/or a thin client technology. This makes the core tech- 
nology high level accessible, thereby transforming any core 
technology into client server, or hidden client technology. 
The browser is located on the client, and the browser 
leverages the object manager. Accordingly, the browser 
optionally contains the object manager, and the object 
manager makes requests over, for example, the Internet, 
local network, and the like via a server, to the engine object. 
The server would be either a web server or a LAN server. 

The present invention also advantageously provides the 
ability to have the client and the server, in a distributed 
environment as discussed above, or on the same machine 
locally. The present invention utilizes the DCOM commu- 
nication protocol defining the communication protocol 
between the object manager and the engine object compo- 
nent. Accordingly, since DCOM can work on the same 
machine as well as in a distributed environment, DCOM 
does not necessitate that the engine object or the object 
manager component be on two separate machines. 

FIG. 21 is an illustration of a distributed environment or 
architecture for manually and/or automatically generating 
and/or using reusable software components for network 
environments, such as the Internet. As illustrated in FIG. 21, 
object manager 14 communicates with engine object com- 
ponent 16, 18, 20 via DCOM specification and a networking 
environment, such as the Internet, intranet, and the like 168. 
Other types of component communication may also be 
utilized that provide the capability of a distributed compo- 
nent interaction over a networking environment. 

FIG. 22 is a detailed illustration of the distributed envi- 
ronment or architecture for manually and/or automatically 
generating and/or using reusable software components in the 
Internet environment. In FIG. 22, client 170 includes object 
manager layer 172. Browser/thin client 170 a executes the 
core technology 180, via accessing engine object layer 178 
managed/stored on web server 176a, and communicated via 
the Internet 174a. 

Browser/thin client 182a, located on the same web server 
176a as core technology 180 and engine object layer 178, 
may also be used to execute the core technology 180 via 
object manager layer 184. In this instance, the browser/thin 
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client 182a with the object manager layer 184 is located on 
the same web server 176a as the engine object layer 178. In 
addition, since the present invention utilizes a communica- 
tion protocol between components, for example, DCOM, 

5 that allows a client to also include both the engine object 
component layer and the object manager layer on the same 
machine 186, as well as the core technology. 

FIGS. 23A-23C are illustrations of the image viewer user 
selectable or configurable or programmable interface and/or 

10 functionality associated therewith in accordance with the 
present invention. In FIG. 23 A, user interface 200 for image 
viewing includes viewing frame 202, with dual viewing 
areas 204, 206. Viewing area 204 includes at the periphery, 
previous page activator 208, at the top, document tools 210, 

15 and at the bottom status indicator 214. Viewing area 206 
includes at the periphery, next page activator 212, at the top, 
document tools 214, and at the bottom status indicator 216. 

Advantageously, this user interface is selectable and/or 
customizable by the user, as illustrated below in connection 

20 with this figure and FIGS. 23B-23C. Significantly, the 
image viewer provides the ability to a user to retain or 
develop a specific perspective on viewing a document. One 
of the features of the viewer is therefore the ability to change 
the user's perspective. For example, the user might be 

25 looking at the same document, as a book, as a film, or as a 
bounded or traditional book. This gives the user the ability 
to relate to the document in a fashion that they are comfort- 
able with, depending on the content or depending on the 
user. That is, the image viewer is like a usable selectable 

30 perspective on viewing a document in a plurality of ways. 
FIG. 23B is an illustration of another user selectable 
interface for image viewing. In FIG. 23B, user interface 200' 
for image viewing includes viewing frame 202', with single 
viewing area 204'. Viewing area 204' includes at the top left, 

35 previous page activator 208' and at the top right next page 
indicator 212'. Viewing area 204' also includes at the left 
area document tools 210', and at the bottom status indicator 
214'. Viewing area 204' also includes at the top, multiple 
viewing page area 218, that appears and preferably moves 

40 like a film, and provides viewing of multiple consecutive or 
non-consecutive pages. Advantageously, this user interface 
is selectable and/or customizable by the user, as illustrated 
below in connection with this figure and FIG. 23A and FIG. 
23C. 

45 FIG. 23C is an illustration of another user selectable 
interface for image viewing. In FIG. 23 C, user interface 
200" for image viewing includes viewing frame 202", with 
single viewing area 204'. Viewing area 204" includes at the 
top right, previous page activator 208" and at the bottom left 

50 next page indicator 212". Mewing area 204" also includes at 
the left area document tools 210", and at the bottom status 
indicator 214". Viewing area thus provides a user interface 
to view a document that appears like a bound or more 
traditional book. Advantageously, this user interface is 

55 selectable and/or customizable by the user, as illustrated 
below in connection with this figure and FIGS. 23A-23B. 

FIG. 24 is an illustration of a stand-alone and/or distrib- 
uted environment or architecture for image viewer in client 
server and/or intranet operating environments. The architec- 

60 ture in FIG. 24 provides the capability to perform the viewer 
process off-line. That is, the viewer process 188 provides an 
added feature on top of the object manager layer 14. As 
described above, object manager layer 14 is essentially an 
interface, and the viewer process 188 is an application that 

65 leverages the object manager layer 14. 

The advantage of the viewer process 188 being built on 
the object manager layer 14, which is built on top of the 
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engine object layer 16, 18, 20, is that the viewer process can architecture of the present invention as described herein, 

offset its processing capabilities anywhere in a distributed users automatically become Internet, intranet and/or WEB 

environment. It can have the processing occur at the local enabled. 

station, on a server, and the like, as described below in detail. The present invention also transforms the core technology 
Significantly, the object manager and the engine object 5 and/or viewer process from essentially client based technol- 
component are independent to provide a distributed envi- ogy into a client server and/or a thin client technology. This 
ronment for using the present invention. Rather than com- makes the core technology high level and/or viewer process 
municate within the same technology between the object accessible, thereby transforming any core technology and./ 
manager and the engine object, the object manager and the or viewer process into client server, or hidden client tech- 
engine object component communicate with each other in 10 noiogy. The browser is located on the client, and the browser 
binary mode, via, for example, standard distributed compo- leverages the object manager. Accordingly, the browser 
nent object module (DCOM) communication. optionally contains the object manager, and the object 

As illustrated in FIG. 24, object manager 14 communi- manager makes requests over, for example, the Internet, 

cates with engine object component 16, 18, 20 via DCOM local network, and the like via a server, to the engine object, 

specification 166. Other types of component communication 15 Hie server would be either a web server or a LAN server, 

may also be utilized that provide the capability of a distrib- The present invention also advantageously provides the 

uted component interaction. Object manager 14 is also ability to have the client and the server, in a distributed 

respectively connectable to viewer process 188. environment as discussed above, or on the same machine 

Thus, the engine object component and the object man- locally. The present invention utilizes the DCOM commu- 

ager can leverage current protocols to not only communicate 20 nication protocol defining the communication protocol 

on the same machine, but also on different machines such as between the object manager and the engine object compo- 

a client server and/or intranet and/or Internet environment. nent. Accordingly, since DCOM can work on the same 

The object manager and/or viewer process can be placed on machine as well as in a distributed environment, DCOM 

one machine, and the engine object component on another does not necessitate that the engine object or the object 

machine and have distributed processing, what is otherwise 25 manager component be on two separate machines, 

called thin client processing, distributed processing, wide FIG. 26 is an illustration of a stand-alone and/or distrib- 

area intranet processing. uted environment or architecture for image viewer in net- 

What this allows the present invention to do is to put the work environments, such as the Internet. As illustrated in 

object manager on the thin client, who would accept the FIG. 21, object manager 14 communicates with engine 

request from the user, for example, to perform the viewer 30 object component 16, 18, 20 via DCOM specification and a 

process. The actual request is handled or processed by the networking environment, such as the Internet, intranet, and 

engine object component which generally resides on the the like 168. In addition, object manager layer 14 also 

server. The engine object component contains the horse advantageously communications with viewer process 188a. 

power, or the processing power to process the request. Other types of component communication may also be 

TTie engine object layer is generally located in the same or 35 utilized that provide the capability of a distributed compo- 

substantially same location as where the core technology or nent interaction over a networking environment, 

engine itself is being stored. Alternatively, the engine object FIG. 27 is a detailed illustration of a stand-alone and/or 

layer and the engine may be optionally located in a distrib- distributed environment or architecture for image viewer in 

uted environment on different machines, servers, and the the Internet environment. In FIG. 27, client 170 includes 

like. 40 object manager layer 172. Browser/thin client 170a executes 

FIG. 25 is a detailed illustration of a stand-alone and/or the core technology 180 and/or viewer process 192a, via 

distributed environment or architecture for image viewer in accessing engine object layer 178 managed/stored on web 

client server and/or intranet operating environments. In FIG. server 176a, and communicated via the Internet 174a. 

25, client 170 includes object manager layer 172 with viewer Viewer process 190 is also optionally available to web 

process 192. Client 170 executes the core technology 180, 45 server 176a. 

via accessing engine object layer 178 managed/stored on Browser/thin client 182a, located on the same web server 

server 176, and communicated via server 174. Viewer pro- 176a as core technology 180, viewer process 192a and 

cess 190 is also optionally available to either or both servers engine object layer 178, may also be used to execute the core 

174, 176. technology 180 via object manager layer 184. In this 

Client 182, located on the same server 176 as core 50 instance, the browser/thin client 182a with the object man- 
technology 180 and engine object layer 178, may also be ager layer 184 is located on the same web server 176a as the 
used to execute the core technology 180 and/or viewer engine object layer 178. In addition, since the present 
process 192 via object manager layer 184. In this instance, invention utilizes a communication protocol between 
the client 182 with the object manager layer 184 is located components, for example, DCOM, that allows a client to 
on the same server 176 as the engine object layer 178. In 55 also include both the engine object component layer and the 
addition, since the present invention utilizes a communica- object manager layer on the same machine 186, as well as 
tion protocol between components, for example, DCOM, the core technology and viewer process, 
that allows a client to also include both the engine object The many features and advantages of the invention are 
component layer, viewer process 194 and the object man- apparent from the detailed specification, and thus, it is 
ager layer on the same machine 186, as well as the core 60 intended by the appended claims to cover all such features 
technology. and advantages of the invention which fall within the true 

Further, since the object manager is formatted or con- spirit and scope of the invention. Further, since numerous 

structed of a client technology, the object manager can sit in modifications and variations will readily occur to those 

a standard browser. This means that anyone that has an skilled in the art, it is not desired to limit the invention to the 

Internet browser, i.e., anyone that has access to the world 65 exact construction and operation illustrated and described, 

wide web (WEB) can actually access the core engine tech- and accordingly, all suitable modifications and equivalents 

noiogy and/or viewer process. Thus, by structuring the may be resorted to, falling within the scope of the invention. 
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For example, while the above discussion has separated the 
various functions into separate layers of functionality, the 
layers may be combined, physically and/or logically, and 
various functions may be combined together. While com- 
bining various functions into same or common layers may 
make implementation details more cumbersome, 
nevertheless, the functions described herein may still be 
accomplished to advantageously provide some or all of the 
benefits of the invention described herein. 

Further, as indicated herein, the present invention may be 
used to automate and/or manually expedite the migration of 
a program specific Application Programmer Interface from 
an original state into a generic interface by building an 
object for each engine. The object advantageously provides 
substantially uniform access to the engine and engine set- 
tings associated with the engine. The present invention may 
be applied across a broad range of programming languages 
that utilize similar concepts as described herein. 

What is claimed is: 

1. A distributed computer implemented process for 
migrating at least one program specific Application Pro- 
grammer Interface (API) from an original state into a 
substantially consistent interface by building an object for at 
least one of an engine and a viewer process, the object 
providing substantially uniform access to the at least one of 
the engine having engine settings and the viewer process, 
comprising the steps of: 

(a) providing, on a server, the at least one engine and 
viewer process, each with one or more features to be 
executed; 

(b) providing, on at least one of the server and another 
server connectable to the server, at least one engine 
component or another viewer process configured to 
execute the one or more features by converting the at 
least one program specific Application Programmer 
Interface (API) from the original state into the substan- 
tially consistent interface, and mapping the substan- 
tially consistent interface to the at least one of the 
engine and the viewer process; and 

(c) providing, on a client configured to be connectable to 
the server and optionally configured to be connectable 
to the another server, an object manager layer commu- 
nicable with and managing the at least one engine 
component or the another viewer process via the sub- 
stantially consistent interface. 

2. A distributed computer implemented process according 
to claim 1, wherein the object manager layer is consistendy 
communicable with each engine or the viewer process using 
the at least one engine component via the substantially 
consistent interface. 

3. A distributed computer implemented process according 
to claim 1, wherein the substantially consistent interface 
comprises at least one of a component object module (COM) 
communication protocol and a distributed COM (DCOM) 
protocol. 

4. A distributed computer implemented process according 
to claim 3, wherein the COM protocol comprises an ActiveX 
control. 

5. A distributed computer implemented process according 
to claim 1, wherein the substantially consistent interface 
comprises a binary mode communication protocol. 

6. A distributed computer implemented process according 
to claim 5, wherein the binary mode communication proto- 
col includes a distributed component object module 
(DCOM) protocol. 

7. A distributed computer implemented process according 
to claim 5, wherein the binary mode communication pro to- 
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col provides the capability for the engine component to 
execute independent of the object manager layer. 

8. A distributed computer implemented process according 
to claim 1, wherein the client comprises at least one of a 

5 browser and a thin client, and the server comprises a web 
server. 

9. A distributed computer system for migrating at least 
one program specific Application Programmer Interface 
(API) from an original state into a substantially consistent 

10 interface by building an object for at least one of an engine 
and a viewer process, the object providing substantially 
uniform access to the at least one of the engine having 
engine settings and the viewer process, comprising: 
a server configured to include 
15 the at least one engine and viewer process, each with 
one or more features to be executed; 
at least one engine component or another viewer pro- 
cess configured to execute the one or more features 
by converting the at least one program specific 
20 Application Programmer Interface (API) from the 

original state into the substantially consistent inter- 
face and mapping the substantially consistent inter- 
face to the at least one of the engine and the viewer 
process; and 

25 a client configured to be connectable to said server and 
optionally configured to be connectable to another 
server, said client including an object manager layer 
communicable with and managing the at least one 
engine component or the another viewer process via the 

30 substantially consistent interface. 

10. A distributed computer system according to claim 9, 
wherein the object manager layer is consistently communi- 
cable with each engine using the at least one engine com- 
ponent via the substantially consistent interface. 

35 11. A distributed computer system according to claim 9, 
wherein the substantially consistent interface comprises at 
least one of a component object module (COM) protocol and 
a distributed COM (DCOM) protocoL 

12. A distributed computer system according to claim 11, 
40 wherein the COM protocol comprises an ActiveX control. 

13. A distributed computer system according to claim 9, 
wherein the substantially consistent interface comprises a 
binary mode communication protocol. 

14. A distributed computer system according to claim 13, 
45 wherein the binary mode communication protocol includes 

a distributed component object module (DCOM) protocoL 

15. A distributed computer system according to claim 9, 
wherein the client comprises at least one of a browser and a 
thin client, and the server comprises a web server. 

50 16. An image viewer process for viewing at least one 
document image including an electronic document image, 
and for performing viewing operations to the electronic 
document image by a user, comprising the steps of: 
55 (a) selecting, by the user, one of a plurality of image 
viewing perspectives, each of the plurality of image 
viewing perspectives providing the user the capability 
of viewing the document image in accordance with a 
different predefined user perspective; 
60 (b) selecting, by the user, using the image viewer process 
the document image to be viewed; 

(c) retrieving, by the image viewer process, the document 
image; 

(d) providing by at least one of the user and a computer 
65 at least one substantially consistent program specific 

Application Programmer Interface (API) for the at least 
two processing application; and 
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(e) displaying, by the image viewer process, the document 
image selected by the user in said selecting step (b), 
using the at least one substantially consistent API 
provided in said providing step (d), in accordance with 
the one of a plurality of imaging viewing perspectives 
selected by the user in said selecting step (a). 

17. A distributed computer implemented process includ- 
ing an object providing substantially uniform access to at 
least one engine having engine settings associated with the 
engine and an engine interface for accessing the engine 
settings and one or more features to be executed, comprising 
the steps of: 

(a) providing, on at least one of the server and another 
server connectable to the server, at least one engine 
component configured to execute the one or more 
features of the engine by mapping a substantially 
consistent interface to the engine interface of the 
engine; and 

(b) providing, on a client configured to be connectable to 
the server and optionally configured to be connectable 
to the another server, an object manager layer commu- 
nicable with and managing the at least one engine 
component via the substantially consistent interface. 

18. A distributed computer system, comprising: 
a server configured to include 

at least one engine having an engine interface, and 

providing one or more features to be executed; 
at least one engine component configured to execute 
the one or more features of the engine by mapping a 
substantially consistent interface to the engine inter- 
face of the engine; and 
a client configured to be connectable to said server and 
optionally configured to be connectable to another 
server, said client including an object manager layer 
communicable with and managing the at least one 
engine component stored on said server via the sub- 
stantially consistent interface. 

19. In a computer architecture including an engine man- 
agement layer interfacing with a program specific applica- 
tion programmer interface (API) and providing engine man- 
agement and administration, an engine configuration layer 
transforming API calls received from the program specific 
API into standardized calls, and an engine layer managing 
the standardized calls for each engine, said engine manage- 
ment layer configuring the computer architecture to perform 
at least one of the following computer implemented or 
computer assisted operations: 

(a) loading and unloading engine dynamic link libraries 
into and out of memory for each engine; 

(b) mapping at least one engine function to at least one 
corresponding engine object; 
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(c) providing general error detection and error correction 
for each engine; 

(d) determining and matching arguments and returning 
values for mapping the at least one engine function to 
the at least one corresponding engine object; and 

(e) managing error feedback from the at least one program 
specific API. 

20. A computer implemented method utilizing a substan- 
tially consistent interface for individual object components 
that represent diverse technologies, comprising the steps of: 

(a) migrating a plurality of engines to the consistent 
interface; and 

(b) at least one of substantially automatically and sub- 
stantially uniformly, managing the individual object 
components using a predefined object manager and the 
consistent interface. 

21. A computer implemented process, comprising one or 
more of the following steps: 

(a) providing the user an engine management function 
furnishing a protective wrapper for each function call 
associated with the engine, trapping errors, and pro- 
viding error management and administration to prevent 
conditions associated with improper engine function- 
ing; 

(b) providing the user an engine configuration function 
transforming application programmer interface (API) 
calls received from the program specific API into 
standardized calls, the engine configuration function 
providing additional functionality, including safely 
loading and unloading the engine; and 

(c) providing the user an engine function managing the 
standardized calls for each engine, thereby providing 
substantially uniform access to the engine and the 
engine settings associated with the engine. 

22. A distributed computer implemented process includ- 
ing an object providing substantially uniform access to at 
least one engine having engine settings associated with the 
engine and an engine interface for accessing the engine 
settings and one or more features to be executed, comprising 
the steps of: 

(a) executing, on at least one of the server and another 
server connectable to the server, at least one engine 
component to thereby execute the one or more features 
of the engine via a substantially consistent interface to 
the engine interface of the engine; and 

(b) managing, on a client configured to be connectable to 
the server and optionally configured to be connectable 
to the another server, an object manager layer to 
manage the at least one engine component via the 
substantially consistent interface. 
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SMART STUB OR ENTERPRISE JAVA™ server 103. A client often handles direct interactions with 

BEAN IN A DISTRIBUTED PROCESSING end users, such as accepting requests and displaying results. 

SYSTEM A variety of different types of software may be used to 

program application server 103 and/or client 105. One 

CROSS REFERENCE TO RELATED 5 programming language is the Java™ programming lan- 

APPLICATIONS guage. Java™ application object code is loaded into a 

. 4 . . . ... Ci r no t» • • i Java™ virtual machine ("JVM"). A JVM is a program 

This application claims the benefit of U.S. Provisional , , , 4 • j • u* u i * *• i 

a i- xr tnnnrr 1*-, d a xt c inno loaded onto a processing device which emulates a particular 

Application No. 60/107,167, filed Nov. 5, 1998. . . * • j • »/ • c «• tU 

rr ' machine or processing device. More information on the 

The following copending U.S. patent applications arc 10 j ava TM programming language may be obtained at http:// 

assigned to the assignee of the present application, and their www.javasoft.com, which is incorporated by reference 

disclosures are incorporated herein by reference: herein. 

(A) Ser. No. 09/405,318 filed Sep. 23, 1999 by Dean B. FIG. lb illustrates several Java™ Enterprise Application 
Jacobs and Anno R. Langen, and originally entitled, Programming Interfaces ("APIs") 100 that allow Java™ 
"CLUSTERED ENTERPRISE JAVA™ HAVING A is application code to remain independent from underlying 
MESSAGE PASSING KERNEL IN A DISTRIBUTED transaction systems, data-bases and network infrastructure. 
PROCESSING SYSTEM"; j ava ™ Enterprise APIs 100 include, for example, remote 

(B) Ser. No. 09/405,508 filed Sep. 23, 1999 by Dean B. method invocation ("RMI") 100a, EJBs 100*, and Java™ 
Jacobs and Eric M. Halpern, and entitled, "A DUPLI- Naming and Directory Interface (JNDI) 100c. 

CATED NAMING SERVICE IN A DISTRIBUTED 20 r MI ^ a ^ a distributed programming model often used 

PROCESSING SYSTEM"; and in peer-to-peer architecture described below. In particular, a 

(C) Ser. No. 09/405,500 filed Sep. 23, 1999 by Dean B. set of classes and interfaces enables one Java™ object to call 
Jacobs and Anno R. Langen, and originally entitled, the public method of another Java™ object running on a 
"CLUSTERED ENTERPRISE JAVA™ IN A SECURE different JVM. 

DISTRIBUTED PROCESSING SYSTEM". 25 An instance of EJB 100£> is typically used in a client/ 

server architecture described above. An instance of EJB 

FIELD OF THE INVENTION lOOfc is a software component or a reusable pre-built piece 

„ . . - j * » *i_ * j • of encapsulated application code that can be combined with 

The present invention relates to distributed processing 4 , r . „ . 4 CT ?ir> iaal 

r , . . . , • * -u . 5 omer components. Typically, an instance of EJB lOOo con- 
systems and, in particular, computer software in distributed 30 „ • . * , - A rm iaal ■ * * j 
J * t tains business logic. An EJB lOOo instance stored on server 
processing sys ems. typically manages persistence, transactions, 
BACKGROUND OF THE INVENTION concurrency, threading, and security. 

JNDI 100c provides directory and naming functions to 

There are several types of distributed processing systems. Java™ software applications. 

Generally, a distributed processing system includes a plu- 35 Client/server architecture 110 has many disadvantages, 

rality of processing devices, such as two computers coupled First, architecture 110 does not scale well because server 103 

to a communication medium. Communication mediums may has to handle many connections. In other words, the number 

include wired mediums, wireless mediums, or combinations Q f clients which may be added to server 103 is limited. In 

thereof, such as an Ethernet local area network or a cellular ^ addition, adding twice as many processing devices (clients) 

network. In a distributed processing system, at least one does no t necessarily provide you with twice as much per- 

processing device may transfer information on the commu- formance. Second, it is difficult to maintain application code 

nication medium to another processing device, G n clients 105 and 108. Third, architecture 110 is susceptible 

Client/server architecture 110 illustrated in FIG. la is one to system failures or a single point of failure. If server 101 

type of distributed processing system. Client/server archi- 45 fails and a backup is not available, client 105 will not be able 

tecture 110 includes at least two processing devices, ill us- to obtain the service. 

trated as client 105 and application server 103. Additional FIG. lc illustrates a multi-tier architecture 160. Clients 

clients may also be coupled to communication medium 104, 151, 152 manage direct interactions with end users, accept- 

such as client 108. ing requests and display results. Application server 153 

Typically, server 103 hosts business logic and/or coordi- 50 hosts the application code, coordinates communications, 

nates transactions in providing a service to another process- synchronizations, and transactions. Database server 154 and 

ing device, such as client 103 and/or client 108. Application portable storage device 155 provides durable transactional 

server 103 is typically programmed with software for pro- management of the data. 

viding a service. The software may be programmed using a Multi-tier architecture 160 has similar client/server archi- 
variety of programming models, such as Enterprise Java™ 55 tecture 110 disadvantages described above. 
Bean ("EJB") lOOfc as illustrated in FIGS. la-b. The service FIG. 2 illustrates peer-to-peer architecture 214. Process- 
may include, for example, retrieving and transferring data ing devices 216, 217 and 218 are coupled to communication 
from a database, providing an image and/or calculating an medium 213. Processing devices 216, 217, and 218 include 
equation. For example, server 103 may retrieve data from network software 210a, 210b, and 210c for communicating 
database 101a in persistent storage 101 over communication 60 over medium 213. Typically, each processing device in a 
medium 102 in response to a request from client 105. peer-to-peer architecture has similar processing capabilities 
Application server 103 then may transfer the requested data and applications. Examples of peer-to-peer program models 
over communication medium 104 to client 105. include Common Object Request Broker Architecture 
A client is a processing device which utilizes a service ("CORBA") and Distributed Object Component Model 
from a server and may request the service. Often a user 106 65 ("DCOM") architecture. 

interacts with client 106 and may cause client 105 to request In a platform specific distributed processing system, each 

service over a communication medium 104 from application processing device may run the same operating system. This 
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allows the use of proprietary hardware, such as shared disks, 
multi-tailed disks, and high speed interconnects, for com- 
municating between processing devices. Examples of 
platform-specific distributed processing systems include 
IBM® Corporation's S/390® Parallel Sysplex®, Compaq's 
Tandem Division Himalaya servers, Compaq's Digital 
Equipment Corporation™ (DEC™) Division Open VMS™ 
Cluster software, and Microsoft® Corporation Windows 
NT® cluster services (Wolfpack). 

FIG. 2b illustrates a transaction processing (TP) architec- 
ture 220. In particular, TP architecture 220 illustrates a 
BEA® Systems, Inc. TUXEDO® architecture. TP monitor 

224 is coupled to processing devices ATM 221, PC 222, and 
TP monitor 223 by communication medium 280, 281, and 
282, respectively. ATM 221 may be an automated teller 
machine, PC 222 may be a personal computer, and TP 
monitor 223 may be another transaction processor monitor. 
TP monitor 224 is coupled to back-end servers 225, 226, and 
227 by communication mediums 283, 284, and 285. Server 

225 is coupled to persistent storage device 287, storing 
database 289, by communication medium 286. TP monitor 
224 includes a workflow controller 224a for routing service 
requests from processing devices, such as ATM 221, PC 222, 
or TP monitor 223, to various servers such as server 225, 226 
and 227. Work flow controller 224a enables (1) workload 
balancing between servers, (2) limited scalability or allow- 
ing for additional servers and/or clients, (3) fault tolerance 
of redundant backend servers (or a service request may be 
sent by a workflow controller to a server which has not 
failed), and (4) session concentration to limit the number of 
simultaneous connections to back-end servers. Examples of 
other transaction processing architectures include IBM® 
Corporation's CICS®, Compaq's Tandem Division 
Pathway/Ford/TS, Compaq's DEC™ ACMS, and Transarc 
Corporation's Encina. 

TP architecture 220 also has many disadvantages. First, a 
failure of a single processing device or TP monitor 224 may 
render the network inoperable. Second, the scalability or 
number of processing devices (both servers and clients) 
coupled to TP monitor 224 may be limited by TP monitor 
224 hardware and software. Third, flexibility in routing a 
client request to a server is limited. For example, if com- 
munication medium 280 is inoperable, but communication 
medium 290 becomes available, ATM 221 typically may not 
request service directly from server 225 over communica- 
tion medium 290 and must access TP monitor 224. Fourth, 
a client typically does not know the state of a back-end 
server or other processing device. Fifth, no industry standard 
software or APIs are used for load balancing. And sixth, a 
client typically may not select a particular server even if the 
client has relevant information which would enable efficient 
service. 

Therefore, it is desirable to provide a distributed process- 
ing system and, in particular, distributed processing system 
software that has the advantages of the prior art distributed 
processing systems without the inherent disadvantages. The 
software should allow for industry standard APIs which are 
typically used in either client/server, multi-tier, or peer-to- 
peer distributed processing systems. The software should 
support a variety of computer programming models. Further, 
the software should enable (1) enhanced fault tolerance, (2) 
efficient scalability, (3) effective load balancing, and (4) 
session concentration control. The improved computer soft- 
ware should allow for rerouting or network reconfiguration. 
Also, the computer software should allow for the determi- 
nation of the state of a processing device. 

SUMMARY OF THE INVENTION 
An improved distributed processing system is provided 
and, in particular, computer software for a distributed pro- 



cessing system is provided. The computer software 
improves the fault tolerance of the distributed processing 
system as well as enables efficient scalability. The computer 
software allows for efficient load balancing and session 

5 concentration. The computer software supports rerouting or 
reconfiguration of a computer network. The computer soft- 
ware supports a variety of computer programming models 
and allows for the use of industry standard APIs that are used 
in both client/server and peer-to-peer distributed processing 

1Q architectures. The computer software enables a detenmna- 
tion of the state of a server or other processing device. The 
computer software also supports message forwarding under 
a variety of circumstances, including a security model. 

According to one aspect of the present invention, a 
distributed processing system comprises a communication 

15 medium coupled to a first processing device and a second 
processing device. The first processing device includes a 
first software program emulating a processing device 
("JVM1") including a first kernel software layer having a 
data structure ("RJVM1"). The second processing device 

20 includes a first software program emulating a processing 
device ("JVM2") including a first kernel software layer 
having a data structure ("RJVM2"). A message from the first 
processing device is transferred to the second processing 
device through the first kernel software layer and the first 

25 software program in the first processing device to the first 
kernel software layer and the first software program in the 
second processing device. 

According to another aspect of the present invention, the 
first software program in the first processing device is a 

30 Java™ virtual machine ("JVM") and the data structure in the 
first processing device is a remote Java™ virtual machine 
("RJVM"). Similarly, the first software program in the 
second processing device is a JVM and the data structure in 
the second processing device is a RJVM. The RJVM in the 

35 second processing device corresponds to the JVM in the first 
processing device. 

According to another aspect of the present invention, the 
RJVM in the first processing device includes a socket 
manager software component, a thread manager software 
component, a message routing software component, a mes- 
sage compression software component, and/or a peer-gone 
detection software component. 

According to another aspect of the present invention, the 

45 first processing device communicates with the second pro- 
cessing device using a protocol selected from the group 
consisting of Transmission Control Protocol ("TCP"), 
Secure Sockets Layer ("SSL"), Hypertext Transport Proto- 
col ("HTTP") tunneling, and Internet InterORB Protocol 

50 ("HOP") tunneling. 

According to another aspect of the present invention, the 
first processing device includes memory storage for a Java™ 
application. 

According to another aspect of the present invention, the 
55 first processing device is a peer of the second processing 
device. Also, the first processing device is a server and the 
second processing device is a client. 

According to another aspect of the present invention, a 
second communication medium is coupled to the second 
60 processing device. A third processing device is coupled to 
the second communication medium. The third processing 
device includes a first software program emulating a pro- 
cessing device ("JVM3"), including a kernel software layer 
having a first data structure ("RJVM1"), and a second data 
65 structure ("RJVM2"). 

According to still another aspect of the present invention, 
the first processing device includes a stub having a replica- 
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handler software component. The replica-handler software According to another aspect of the present invention, a 

component includes a load balancing software component stub is stored in a processing device in a distributed pro- 

and a failover software component. cessing system. The stub includes a method comprising the 

According to another aspect of the present invention, the steps of obtaining a list of service providers and selecting a 

first processing device includes an Enterprise Java™ Bean 5 service provider from the list of service providers, 
object. According to another aspect of the present invention, the 

According to still another aspect of the present invention, me thod further includes removing a failed service provider 

the first processing device includes a naming tree having a from the list of service prov j ders . 
pool of stubs stored at a node of the tree and the second , .„ , _ . . 

processing device includes a duplicate of the naming tree. 10 According to still another aspect of the present invention 

According to still another aspect of the present invention, an a £> aratus emprises a communication medium coupled 

the first processing device includes an application program * a ^ Pressing device and a second processing device, 

coded in a stateless program model and the application ™* &st processing device stores a naming tree including a 

program includes a stateless session bean. remote method evocation ("RMI") stub for accessing a 

According to still another aspect of the present invention, 15 ^ P rovi ? er * ^ f™* Pressing device has a dupli- 

the first processing device includes an application program cate namm § tree and the *™* P r0Vlder ' 
coded in a stateless factory program model and the appli- According to another aspect of the present invention, the 

cation program includes a stateful session bean. naming tree has a node including a service pool of current 

According to still another aspect of the present invention, service providers, 
the first processing device includes an application program 20 According to another aspect of the present invention, the 

coded in a stateful program model and the application service pool includes a stub. 

program includes an entity session bean. According to another aspect of the present invention, a 

According to still another aspect of the present invention, distributed processing system comprises a first computer 
an article of manufacture including an information storage coupled to a second computer. The first computer has a 
medium is provided. The article of manufacture comprises a 25 naming tree, including a remote invocation stub for access- 
first set of digital information for transferring a message ing a service provider. The second computer has a replicated 
from a RJVM in a first processing device to a RJVM in a naming tree and the service provider, 
second processing device. According to another aspect of the present invention, a 

According to another aspect of the present invention, the distributed processing system comprising a first processing 

article of manufacture comprises a first set of digital 30 device coupled to a second processing device is provided, 

information, including a stub having a load balancing soft- The first processing device has a JVM and a first kernel 

ware program for selecting a service provider from a plu- software layer including a first RJVM. The second process- 

rality of service providers. ing device includes a first JVM and a first kernel software 

According to another aspect of the present invention, the layer including a second RJVM. A message may be trans- 
stub has a failover software component for removing a failed 35 ferred from the first processing device to the second pro- 
service provider from the plurality of service providers. cessing device when there is not a socket available between 

According to another aspect of the present invention, the the first JVM and the second JVM. 
load balancing software component selects a service pro- According to another aspect of the present invention, the 

vider based on an affinity for a particular service provider. first processing device is running under an applet security 

According to another aspect of the present invention, the 40 model, behind a firewall or is a client, and the second 

load balancing software component selects a service pro- processing device is also a client. 

vider in a round robin manner. Other aspects and advantages of the present invention can 

According to another aspect of the present invention, the be seen upon review of the figures, the detailed description, 

load balancing software component randomly selects a ^ and the claims which follow, 
service provider. 

According to another aspect of the present invention, the BRIEF DESCRIPTION OF THE FIGURES 

load balancing software component selects a service pro- nG u illustratcs a rior ^ c ii en t/server architecture; 
vider from the plurality of service providers based upon the . , . 

load of each service provider. 5Q lb Pirates a prior art Java™ enterprise APIs; 

According to another aspect of the present invention, the FIG - lc illustrates a multi-tier architecture; 
load balancing software component selects a service pro- FIG- 2a illustrates a prior art peer-to-peer architecture; 
vider from the plurality of service providers based upon the FIG. 2b illustrates a prior art transaction processing 

data type requested. architecture; 

According to another aspect of the present invention, the 55 piG. 3a illustrates a simplified software block diagram of 

load balancing software component selects a service pro- a n embodiment of the present invention; 
vider from the plurality of service providers based upon the fig. 3b illustrates a simplified software block diagram of 

closest physical service provider. ^ kemel mus ^ d io FIG . 3fl . 

According to another aspect of the present invention, the - ... . 4 . t , . T -„ ... 

, , , , . - r * t . • FIG. 3c illustrates a clustered enterprise Java™ architec- 

load balancing software component selects a service pro- 60 ^ 

vider from the plurality of service providers based upon a * 4 

time period in which each service provider responds. mG - 4 grates a clustered enterpnse Java™ naming 

service architecture* 

According to another aspect of the present invention, the ' 
article of manufacture comprises a first set of digital nG - 5a iU^trates a smart stub architecture; 
information, including an Enterprise Java™ Bean object for 65 FIG. 5b illustrates an EJB object architecture; 
selecting a service provider from a plurality of service FIG. 6a is a control flow chart illustrating a load balancing 

providers. method; 
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FIGS. 6b-g are control flow charts illustrating load bal- description describes one particular type of processing 

ancing methods; device where multiple other types of processing devices 

FIG. 7 is a control flow chart illustrating a failover with a different software and hardware configurations could 

method; be utilized in accordance with an embodiment of the present 

FIG. 8 illustrates hardware and software components of a 5 invention. In an alternate embodiment, a processing device 

client/server in the clustered enterprise Java™ architecture may be a printer, handheld computer, laptop computer, 

shown in FIGS. 3-5. scanner, cellular telephone, pager, or equivalent thereof. 

The invention will be better understood with reference to nG - 3c illustrates an embodiment of the present invention 

the drawings and detailed description below. In the in which servers 302 and 303 are coupled to communication 

drawings, like reference numerals indicate like components. medium 301, Server 303 is also coupled to communication 

medium 305 which may have similar embodiments as 

DETAILED DESCRIPTION described above in regard to communication medium 301. 

I. Clustered Enterprise Java™ Distributed Processing Sys- CUent f4 is also coupled to communication medium 305. 

tem 15 In an alternate embodiment, client 304 may be coupled to 

A. Clustered Enterprise Java™ Software Architecture communication medium 301 as illustrated by the dashed line 
FIG. 3a illustrates a simplified block diagram 380 of the and b°x in FIG. 3c. It should be understood that in alternate 

software layers in a processing device of a clustered enter- embodiments, server 302 is (1) both a client and a server, or 

prise Java™ system, according to an embodiment of the (2) a client. Similarly, FIG. 3 illustrates an embodiment in 

present invention. A detailed description of a clustered 20 which three processing devices are shown wherein other 

enterprise Java™ distributed processing system is described embodiments of the present invention include multiple other 

below. The first layer of software includes a communication processing devices or communication mediums as illus- 

medium software driver 351 for transferring and receiving trated by the ellipses. 

information on a communication medium, such as an eth- Server 302 transfers information over communication 

ernet local area network. An operating system 310 including 25 medium 301 to server 303 by using network software 302a 

a transmission control protocol ("TCP") software compo- and network software 303a, respectively. In an embodiment, 

nent 353 and internet protocol ("IP") software component network software 302a, 303a, and 304a include communi- 

352 are upper software layers for retrieving and sending cation medium software driver 351, Transmission Control 

packages or blocks of information in a particular format. An Protocol software 353, and Internet Protocol software 352 

"upper" software layer is generally defined as a software 30 ("TCP/IP'). Client 304 also includes network software 304a 

component which utilizes or accesses one or more "lower" for transferring information to server 303 over communica- 

so ft ware layers or software components. A JVM 354 is then tion medium 305. Network software 303a in server 303 is 

implemented. A kernel 355 having a remote Java™ virtual also used to transfer information to client 304 by way of 

machine 356 is then layered on JVM 354. Kernel 355. communication medium 305. 

described in detail below, is used to transfer messages 35 According to an embodiment of the present invention, 

between processing devices in a clustered enterprise Java™ each processing device in clustered enterprise Java™ archi- 

distributed processing system. Remote method invocation lecture 300 includes a message-passing kernel 355 that 

357 and enterprise Java™ bean 358 are upper software supports both multi-tier and peer-to-peer functionality. A 

layers of kernel 355. EJB 358 is a container for a variety of kernel is a software program used to provide fundamental 

Java™ applications. 40 services to other software programs on a processing device. 

FIG. 3£> illustrates a detailed view of kernel 355 illustrated In particular, server 302, server 303, and client 304 have 

in FIG. 3a. Kernel 355 includes a socket manager compo- kernels 302f>, 303Z>, and 304/>, respectively. In particular, in 

nent 363, thread manager 364 component, and RJVM 356. order for two JVMs to interact, whether they are clients or 

RJVM 356 is a data structure including message routing servers, each JVM constructs an RJVM representing the 

software component 360, message compression software 45 other. Messages are sent from the upper layer on one side, 

component 361 including abbreviation table 161c, and peer- through a corresponding RJVM, across the communication 

gone detection software component 362. RJVM 356 and medium, through the peer RJVM, and delivered to the upper 

thread manager component 364 interact with socket man- layer on the other side. In various embodiments, messages 

ager component 363 to transfer information between pro- can be transferred using a variety of different protocols, 

cessing devices. 50 including, but not limited to, Transmission Control Protocol/ 

B. Distributed Processing System Internet Protocol ("TCP/IP"), Secure Sockets Layer 
FIG. 3 illustrates a simplified block diagram of a clustered ("SSL"), Hypertext Transport Protocol ("HTTP**) tunneling, 

enterprise Java™ distributed processing system 300. Pro- and Internet InterORB Protocol ("HOP*) tunneling, and 

cessing devices are coupled to communication medium 301. combinations thereof. The RJVMs and socket managers 

Communication medium 301 may be a wired and/or wire- 55 create and maintain the sockets underlying these protocols 

less communication medium or combination thereof. In an and share them between all objects in the upper layers. A 

embodiment, communication medium 301 is a local-area- socket is a logical location representing a terminal between 

network (LAN). In an alternate embodiment, communica- processing devices in a distributed processing system. The 

tion medium 301 is a world-area-network (WAN) such as kernel maintains a pool of execute threads and thread 

the Internet or World Wide Web. In still another 60 manager software component 364 multiplexes the threads 

embodiment, communication medium 301 is both a LAN between socket reading and request execution. A thread is a 

and a WAN. sequence of executing program code segments or functions. 

A variety of different types of processing devices may be For example, server 302 includes JVM1 and Java™ 

coupled to communication medium 301. In an embodiment, application 302c. Server 302 also includes a RJVM2 repre- 

a processing device may be a general purpose computer 100 65 senting the JVM2 of server 303. If a message is to be sent 

as illustrated in FIG. 8 and described below. One of ordinary from server 302 to server 303, the message is sent through 

skill in the art would understand that FIG. 8 and the below RJVM2 in server 302 to RJVM1 in server 303. 
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C. Message Forwarding 

Clustered enterprise Java™ network 300 is able to for- 
ward a message through an intermediate server. This func- 
tionality is important if a client requests a service from a 
back-end server through a front -end gateway. For example, 
a message from server 302 (client 302) and, in particular, 
JVM1 may be forwarded to client 304 (back-end server 304) 
or JVM3 through server 303 (front-end gateway) or JVM2. 
This functionality is important in controlling session con- 
centration or how many connections are established between 
a server and various clients. 

Further, message forwarding may be used in circum- 
stances where a socket cannot be created between two 
JVMs. For example, a sender of a message is running under 
the applet security model which does not allow for a socket 
to be created to the original server. A detailed description of 
the applet security model is provided at http// 
:www.javasoft.com, which is incorporated herein by refer- 
ence. Another example includes when the receiver of the 
message is behind a firewall. Also, as described below, 
message forwarding is applicable if the sender is a client and 
the receiver is a client and thus does not accept incoming 
sockets. 

For example, if a message is sent from server 302 to client 
304, the message would have to be routed through server 
303. In particular, a message handofl, as illustrated by 302/, 
between RJVM3 (representing client 304) would be made to 
RJVM2 (representing server 303) in server 302. The mes- 
sage would be transferred using sockets 302e between 
RJVM2 in server 302 and RJVM1 in server 303. The 
message would then be handed off, as illustrated by dashed 
line 303/, from RJVM1 to RJVM3 in server 303. The 
message would then be passed between sockets of RJVM3 
in server 303 and RJVM2 in client 304. The message then 
would be passed, as illustrated by the dashed line 304/, from 
RJVM2 in client 304 to RJVM1 in client 304. 

D. Rerouting 

An RJVM in client/server is able to switch communica- 
tion paths or communication mediums to other RJVMs at 
any time. For example, if client 304 creates a direct socket 
to server 302, server 302 is able to start using the socket 
instead of message forwarding through server 303. This 
embodiment is illustrated by a dashed line and box repre- 
senting client 304. In an embodiment, the use of transferring 
messages by RJVMs ensures reliable, in-order message 
delivery after the occurrence of a network reconfiguration. 
For example, if client 304 was reconfigured to communica- 
tion medium 301 instead of communication medium 305 as 
illustrated in FIG. 3. In an alternate embodiment, messages 
may not be delivered in order. 

An RJVM performs several end-to-end operations that are 
carried through routing. First, an RJVM is responsible for 
detecting when a respective client/server has unexpectedly 
died. In an embodiment, peer-gone selection software com- 
ponent 362, as illustrated in FIG. 36, is responsible for this 
function. In an embodiment, an RJVM sends a heartbeat 
message to other clients/servers when no other message has 
been sent in a predetermined time period. If the client/server 
does not receive a heartbeat message in the predetermined 
count time, a failed client/server which should have sent the 
heartbeat, is detected. In an embodiment, a failed client/ 
server is detected by connection timeouts or if no messages 
have been sent by the failed client/server in a predetermined 
amount of time. In still another embodiment, a failed socket 
indicates a failed server/client. 

Second, during message serialization, RJVMs, in 
particular, message compression software 360, abbreviate 
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commonly transmitted data values to reduce message size. 
To accomplish this, each JVM/RJVM pair maintains match- 
ing abbreviation tables. For example, JVM1 includes an 
abbreviation table and RJVM1 includes a matching abbre- 
5 viation table. During message forwarding between an inter- 
mediate server, the body of a message is not deserialized on 
the intermediate server in route. 

E. Muiti-tier/Peer-to-Peer Functionality 

Clustered enterprise Java™ architecture 300 allows for 
10 multitier and peer-to-peer programming. 

Clustered enterprise Java™ architecture 300 supports an 
explicit syntax for client/server programming consistent 
with a multitier distributed processing architecture. As an 
example, the following client-side code fragment writes an 
15 informational message to a server's log file: 

T3Client cint-new T3Client("t3://acme:7001"); 

LogServices log«clnt.getT3Services( ).log( ); 

log.info("Hello from a client"); 
20 The first line establishes a session with the acme server 
using the t3 protocol. If RJVMs do not already exist, each 
JVM constructs an RJVM for the other and an underlying 
TCP socket is established. The client-side representation of 
this session — the T3Client object — and the server-side rep- 
25 resentation communicate through these RJVMs. The server- 
side supports a variety of services, including database 
access, remote file access, workspaces, events, and logging. 
The second line obtains a LogServices object and the third 
line writes the message. 
30 Clustered enterprise Java™ computer architecture 300 
also supports a server-neutral syntax consistent with a peer- 
to-peer distributed processing architecture. As an example, 
the following code fragment obtains a stub for an RMI 
object from the JND I -compliant naming service on a server 
35 and invokes one of its methods. 

Hashtable env=new Hashtable( ); 

env,put(Context.PROVIDER_URL, "t3://acme:7001"); 

env.put<Context.IMTIAL_CONTEXT_FACTORY, 

"weblogic.jndi.WebLogicinitialContextFactory"); 

Context ctx=new InitialContext(env); 

Example e=(Example) ctx.lookup^acme.eng.example"); 

result=e .example(37); 

In an embodiment, JND I naming contexts are packaged as 

45 RMI objects to implement remote access. TTius, the above 
code illustrates a kind of RMI bootstrapping. The first four 
lines obtain an RMI stub for the initial context on the acme 
server. If RJVMs do not already exist, each side constructs 
an RJVM for the other and an underlying TCP socket for the 

50 t3 protocol is established. The caller^side object — the RMI 
stub — and the callee-side object — an RMI impl- 
communicate through the RJVMs. The fifth line looks up 
another RMI object, an Example, at the name acme.eng.ex- 
ample and the sixth line invokes one of the Example 

55 methods. In an embodiment, the Example impl is not on the 
same processing device as the naming service. In another 
embodiment, the Example impl is on a client. Invocation of 
the Example object leads to the creation of the appropriate 
RJVMs if they do not already exist. 

60 II. Replica-Aware or Smart Stubs/EJB Objects 

In FIG. 3c, a processing device is able to provide a service 
to other processing devices in architecture 300 by replicating 
RMI and/or EJB objects. Thus, architecture 300 is easily 
scalable and fault tolerant. An additional service may easily 

65 be added to architecture 300 by adding replicated RMI 
and/or EJB objects to an existing processing device or newly 
added processing device. Moreover, because the RMI and/or 
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EJB objects can be replicated throughout architecture 300, a 
single processing device, multiple processing devices, and/ 
or a communication medium may fail and still not render 
architecture 300 inoperable or significantly degraded. 

FIG. Sa illustrates a replica -aware ("RA") or Smart stub 
580 in architecture 500. Architecture 500 includes client 504 
coupled to communication medium 501. Servers 502 and 
503 are coupled to communication medium 501, respec- 
tively. Persistent storage device 509 is coupled to server 502 
and 503 by communication medium 560 and 561, respec- 
tively. In various embodiments, communication medium 
501, 560, and 561 may be wired and/or wireless communi- 
cation mediums as described above. Similarly, in an 
embodiment, client 504, server 502, and server 503 may be 
both clients and servers as described above. One of ordinary 
skill in the art would understand that in alternate 
embodiments, multiple other servers and clients may be 
included in architecture 500 as illustrated by ellipses. Also, 
as stated above, in alternate embodiments, the hardware and 
software configuration of client 504, server 502 and server 
503 is described below and illustrated in FIG. 8. 

RA RMI stub 580 is a Smart stub which is able to find out 
about all of the service providers and switch between them 
based on a load balancing method 507 and/or failover 
method 508. In an embodiment, an RA stub 580 includes a 
replica handler 506 that selects an appropriate load balanc- 
ing method 507 and/or failover method 507. In an alternate 
embodiment, a single load balancing method and/or single 
failover method is implemented. In alternate embodiments, 
replica handler 506 may include multiple load balancing 
methods and/or multiple failover methods and combinations 
thereof. In an embodiment, a replica handler 506 imple- 
ments the following interface: 

public interface ReplicaHandler { 

Object loadBalance(Object currentProvider) throws 

RefreshAbortedException; 

Object failOver(Object failedProvider, 
RemoteException e) throws 

RemoteException; 

} 

Immediately before invoking a method, RA stub 580 calls 
load balance method 507, which takes the current server and 
returns a replacement. For example, client 504 may be using 
server 502 for retrieving data for database 509a or personal 
storage device 509. Load balance method 507 may switch to 
server 503 because server 502 is overloaded with service 
requests. Handler 506 may choose a server replacement 
entirely on the caller, perhaps using information about server 
502 load, or handler 506 may request server 502 for retriev- 
ing a particular type of data. For example, handler 506 may 
select a particular server for calculating an equation because 
the server has enhanced calculation capability. In an 
embodiment, replica handler 506 need not actually switch 
providers on every invocation because replica handler 506 is 
trying to minimize the number of connections that are 
created. 

FIG. 6a is a control flow diagram illustrating the load 
balancing software 507 illustrated in FIGS. 5a-b. It should 
be understood that FIG. 6a is a control flow diagram 
illustrating the logical sequence of functions or steps which 
are completed by software in load balancing method 507. In 
alternate embodiments, additional functions or steps are 
completed. Further, in an alternate embodiment, hardware 
may perform a particular function or all the functions. 

Load balancing software 507 begins as indicated by circle 
600. A determination is then made in logic block 601 as to 
whether the calling thread established "an affinity" for a 
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particular server. A client has an affinity for the server that 
coordinates its current transaction and a server has an affinity 
for itself. If an affinity is established, control is passed to 
logic block 602, otherwise control is passed to logic block 

5 604. A determination is made in logic block 602 whether the 
affinity server provides the service requested. If so, control 
is passed to logic block 603. Otherwise, control is passed to 
logic block 604. The provider of the service on the affinity 
server is returned to the client in logic block 603. In logic 

10 block 604, a naming service is contacted and an updated list 
of the current service providers is obtained. A getNext Pro- 
vider method is called to obtain a service provider in logic 
block 605. Various embodiments of the getNextProvider 
method are illustrated in FIGS. 6b-g and described in detail 

15 below. The service is obtained in logic block 606. Failover 
method 508 is then called if service is not provided in logic 
block 606 and load balancing method 507 exits as illustrated 
by logic block 608. An embodiment of failover method 508 
is illustrated in FIG. 7 and described in detail below. 

20 FIGS. 6b-g illustrate various embodiments of a getNex- 
tProvider method used in logic block 605 of FIG. 6a. As 
illustrated in FIG. 6b, the getNextProvider method selects a 
service provider in a round robin manner. A getNextProvider 
method 620 is entered as illustrated by circle 621. A list of 

25 current service providers is obtained in logic block 622. A 
pointer is incremented in logic block 623. The next service 
provider is selected based upon the pointer in logic block 

624 and the new service provider is returned in logic block 

625 and getNextProvider method 620 exits as illustrated by 
30 circle 626. 

FIG. 6c illustrates an alternate embodiment of a getNex- 
tProvider method which obtains a service provider by select- 
ing a service provider randomly. A getNextProvider method 
630 is entered as illustrated by circle 631. A list of current 

35 service providers is obtained as illustrated by logic block 
632. The next service provider is selected randomly as 
illustrated by logic block 633 and a new service provider is 
returned in logic block 634. The getNextProvider method 
630 then exits, as illustrated by circle 635. 

40 Still another embodiment of a getNextProvider method is 
illustrated in FIG. 6d which obtains a service provider based 
upon the load of the service providers. A getNextProvider 
method 640 is entered as illustrated by circle 641. A list of 
current service providers is obtained in logic block 642. The 

45 load of each service provider is obtained in logic block 643. 
The service provider with the least load is then selected in 
logic block 644. The new service provider is then returned 
in logic block 645 and getNextProvider method 640 exits as 
illustrated by circle 646. 

50 An alternate embodiment of a getNextProvider method is 
illustrated in FIG. 6e which obtains a service provider based 
upon the type of data obtained from the service provider. A 
getNextProvider method 650 is entered as illustrated by 
circle 651. A list of current service providers is obtained in 

55 logic block 652. The type of data requested from the service 
providers is determined in logic block 653. The service 
provider is then selected based on the data type in logic 
block 654. The service provider is returned in logic block 
655 and getNextProvider method 650 exits as illustrated by 

60 circle 656. 

Still another embodiment of a getNextProvider method is 
illustrated in FIG. 6/ which selects a service provider based 
upon the physical location of the service providers. A 
getNextProvider method 660 is entered as illustrated by 
65 circle 661. A list of service providers is obtained as illus- 
trated by logic block 662. The physical distance to each 
service provider is determined in logic block 663 and the 
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service provider which has the closest physical distance to a field in a database, might have completed. In an 

the requesting client is selected in logic block 664. The new embodiment, RA stub 580 will retry after an infrastructure 

service provider is then returned in logic block 665 and the failure only if either (1) the user has declared that the service 

getNextProvider method 660 exits as illustrated by circle methods are idempotent, or (2) the system can determine 

566 5 that processing of the request never started. As an example 

Still a further embodiment of the getNextProvider method ° f ^e latter, RA stub 580 will retry if, as part of load 
is illustrated in FIG. 6g and selects a service provider based balancing method, stub 580 switches to a service provider 
on the amount of time taken for the service provider to w !j ose host p has failed - ** anothe ' exani P le ' a stub 580 
respond to previous requests. Control of getNextProvider ^ re ^ * "f* a ne § aUve acknowledgment to a trans- 
method 670 is entered as ulustrated by circle 671 A list of 10 RMI^Sir recognizes a special flag that instructs 
current service providers is obtamedm logic block 672. The me aer £ ^ ra stub for „ object . An 
time period for each service prov,der to respond tea additional flag caD te ^ 6 to specify mat the 
particular message is determined in logic block 673. The memo ds are idempotent. In an embodiment, RA stub 580 
service provider which responds in the shortest tune period ^ use ^ replica nand ] cr described above and illustrated 
is selected in logic block 674. The new service provider is 15 ^ piQ ^a. An additional flag may be used to specify a 
then returned in logic block 675 and control from getNex- different handler. In addition, at the point a service is 
tProvider method 670 exits as illustrated by circle 676. deployed, i.e., bound into a clustered naming service as 

If invocation of a service method fails in such a way that described below, the handler may be overridden, 

a retry is warranted, RA 580 stub calls failover method 508, FIG. Sb illustrates another embodiment of the present 

which takes the failed server and an exception indicating 20 invention in which an EJB object 551 is used instead of a 

what the failure was and returns a new server for the retry. stub, as shown in FIG. 5a. 

If a new server is unavailable, RA stub 580 throws an HI. Replicated JNDI -compliant Naming Service 

exception. As illustrated in FIG. 4, access to service providers in 

FIG. 7 is a control flow chart illustrating failover software architecture 400 is obtained through a JNDI-compliant nam- 
508 shown in FIGS. 5a-b. Failover method 508 is entered as 25 ing service, which is replicated across architecture 400 so 
illustrated by circle 700. A failed provider from the list of ^ere is ™ single point of failure. Accordingly, if a process- 
current providers of services is removed in logic block 701. in S device which offers a JNDI-compliant naming service 
A getNextProvider method is then called in order to obtain fails > another processing device having a replicated naming 
a service provider. The new service provider is then returned service is available. To offer an instance of a service, a server 
in logic block 703 and failover method 508 exits as illus- 30 advertises a provider of the service at a particular node in a 
trated by circle 704. replicated naming tree. In an embodiment, each server adds 

While FIGS. 6-7 illustrate embodiments of a replica a stub for thc provider to a compatible service pool 

handler 506, alternate embodiments include the following stored at the node in the server's copy of the naming tree. If 

functions or combinations thereof implemented in a round me type 01 a new offer & incompatible with the type of offers 

robin manner. 35 m an existing pool, the new offer is made pending and a 

First, a list of servers or service providers of a service is callback is made through a ConflictHandler interface. After 

maintained. Whenever the list needs to be used and the list either type of offer * retracted, the other will ultimately be 

has not been recently updated, handler 506 contacts a installed everywhere. When a client looks up the service, the 

naming service as described below and obtains an up-to-date client obtains a RA stub that contacts the service pool to 

list of providers. 40 refresh the client's list of service providers. 

Second, if handler 506 is about to select a provider from FJG. 4 illustrates a replicated naming service in architec- 
the list and there is an existing RJVM-level connection to the tore 400. In an embodiment, servers 302 and 303 offer an 
hosting server over which no messages have been received example service provider PI and P2, respectively, and has a 
during the last heartbeat period, handler 506 skips that replica of the naming service tree 402 and 403, respectively, 
provider. In an embodiment, a server may later recover since 45 The node acme.eng.example in naming service tree 402 and 
death of peer is determined after several such heartbeat 403 has a service pool 402a and 403a, respectively, con- 
periods. Thus, load balancing on the basis of server load is taining a reference to Example service provider PI and P2. 
obtained. Client 304 obtains a RAstub 304e by doing a naming service 

Third, when a provider fails, handler 506 removes the lookup at the acme.eng.example node. Stub 304e contacts an 

provider from the list. This avoids delays caused by repeated 50 instance of a service pool to obtain a current list of refer- 

attempts to use non-working service providers. ences to available service providers. Stub 304e may switch 

Fourth, if a service is being invoked from a server that between the instances of a service pool as needed for 

hosts a provider of the service, then that provider is used. load-balancing and failover. 

This facilitates co-location of providers for chained invokes stubs for ^ initial context of the naming service are 

of services. 55 replica-aware or Smart stubs which initially load balance 

Fifth, if a service is being invoked within the scope of a among naming service providers and switch in the event of 

transaction and the server acting as transaction coordinator a failure. Each instance of the naming service tree contains 

hosts a provider of the service, then that provider is used. a complete list of the current naming service providers. The 

This facilitates co-location of providers within a transaction. stub obtains a fresh list from the instance it is currendy 

The failures that can occur during a method invocation 60 usin S- To bootstrap this process, the system uses Domain 

may be classified as being either (1) application -related, or Naming Service ("DNS") to find a (potentially incomplete) 

(2) infrastructure-related. RA stub 580 will not retry an initial list of instances and obtains the complete list from one 

operation in the event of an application-related failure, since of toern. As an example, a stub for the initial context of the 

there can be no expectation that matters will improve. In the naming service can be obtained as follows: 

event of an infrastructure-related failure, RA stub 580 may 65 Hashtable env=new Hashtable( ); 

or may not be able to safely retry the operation. Some initial env.put(Context.PROVIDER__URL, " 1 3 : // 

non-idempotent operation, such as incrementing the value of acmeCtuster:7001"); 
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env.put(Context.INIT[AL_CONTEXT_FACTORY, 

'*weblogic.jndi .WebLogjcI nitialContextFactor"); 

Context ctx^new InitialContext(env); 

Some subset of the servers in an architecture have been 
bound into DNS under the name acmeCluster. Moreover, an 
application is still able to specify the address of an individual 
server, but the application will then have a single point of 
failure when the application first attempts to obtain a stub. 

A reliable multicast protocol is desirable. In an 
embodiment, provider stubs are distributed and replicated 
naming trees are created by an IP multicast or point-to-point 
protocol. In an IP multicast embodiment, there are three 
kinds of messages: Heartbeats, Announcements, and Stat- 
eDumps. Heartbeats are used to carry information between 
servers and, by their absence, to identify failed servers. An 
Announcement contains a set of offers and retractions of 
services. The Announcements from each server are sequen- 
tially numbered. Each receiver processes an Announcement 
in order to identify lost Announcements. Each server 
includes in its Heartbeats the sequence number of the last 
Announcement it has sent. Negative Acknowledgments 
("NAKs") for a lost Announcement are included in subse- 
quent outgoing Heartbeats. To process NAKs, each server 
keeps a list of the last several Announcements that the server 
has sent. If a NAK arrives for an Announcement that has 
been deleted, the server sends a StateDump, which contains 
a complete list of the server's services and the sequence 
number of its next Announcement. When a new server joins 
an existing architecture, the new server NAKs for the first 
message from each other server, which results in Stat- 
eDumps being sent. If a server does not receive a Heartbeat 
from another server after a predetermined period of time, the 
server retracts all services offered by the server not gener- 
ating a Heartbeat. 
IV. Programming Models 

Applications used in the architecture illustrated in FIGS. 
3-5 use one of three basic programming models: (1) state- 
less or direct, (2) stateless factory or indirect, or (3) statcful 
or targeted, depending on the way the application state is to 
be treated. In the stateless model, a Smart stub returned by 
a naming-service lookup directly references service provid- 
ers. 

Example e=(Example) ctx.lookup("acme.eng.example"); 

resultl-e.example(37); 

result2=e.example(38); 

In this example, the two calls to example may be handled 
by different service providers since the Smart stub is able to 
switch between them in the interests of load balancing. Thus, 
the Example service object cannot internally store informa- 
tion on behalf of the application. Typically the stateless 
model is used only if the provider is stateless. As an 
example, a pure stateless provider might compute some 
mathematical function of its arguments and return the result. 
Stateless providers may store information on their own 
behalf, such as for accounting purposes. More importantly, 
stateless providers may access an underlying persistent 
storage device and load application state into memory on an 
as-needed basis. For example, in order for example to return 
the running sum of all values passed to it as arguments, 
example might read the previous sum from a database, add 
in its current argument, write the new value out, and then 
return it. This stateless service model promotes scalability. 

In the stateless factory programming model, the Smart 
stub returned by the lookup is a factory that creates the 
desired service providers, which are not themselves Smart 
stubs. 
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ExampleFactory gf«(ExampleFactory) 
ctx.lookup("acme.eng.example"); 
Example e=gf.create( ); 
resultl=e.example(37); 
5 result2»e.example(38); 

In this example, the two calls to example are guaranteed 
to be handled by the same service provider. The service 
provider may therefore safely store information on behalf of 
the application. The stateless factory model should be used 
io when the caller needs to engage in a "conversation" with the 
provider. For example, the caller and the provider might 
engage in a back-and-forth negotiation. Replica-aware stubs 
are generally the same in the stateless and stateless factory 
models, the only difference is whether the stubs refer to 
!5 service providers or service provider factories. 

A provider factory stub may failover at will in its effort to 
create a provider, since this operation is idempotent. To 
further increase the availability of an indirect service, appli- 
cation code must contain an explicit retry loop around the 
20 service creation and invocation, 
while (true) { 
try { 

Example e=gf.create( ); 
resultl :=e.example(37); 
25 result2=e.example(38); 
break; 
} catch (Exception e) { 
if (!retryWarranted(e)) 
throw e; 

30 } 

} 

This would, for example, handle the failure of a provider 
e that was successfully created by the factory. In this case, 
application code should determine whether non-idempotent 

35 operations completed. To further increase availability, appli- 
cation code might attempt to undo such operations and retry. 

In the stateful programming model, a service provider is 
a long-lived, stateful object identified by some unique 
system-wide key. Examples of "entities" that might be 

40 accessed using this model include remote file systems and 
rows in a database table. A targeted provider may be 
accessed many times by many clients, unlike the other two 
models where each provider is used once by one client. 
Stubs for targeted providers can be obtained either by direct 

45 lookup, where the key is simply the naming-service name, or 
through a factory, where the key includes arguments to the 
create operation. In either case, the stub will not do load 
balancing or failover. Retries, if any, must explicitly obtain 
the stub again. 

50 There are three kinds of beans in EJB, each of which maps 
to one of the three programming models. Stateless session 
beans are created on behalf of a particular caller, but 
maintain no internal state between calls. Stateless session 
beans map to the stateless model. Stateful session beans are 

55 created on behalf of a particular caller and maintain internal 
state between calls. Stateful session beans map to the 
stateless factory model. Entity beans are singular, stateful 
objects identified by a system- wide key. Entity beans map to 
the stateful model All three types of beans are created by a 

60 factory called an EJB home. In an embodiment, both EJB 
homes and the beans they create are referenced using RMI. 
In an architecture as illustrated in FIGS. 3-5, stubs for an 
EJB home are Smart stubs. Stubs for stateless session beans 
are Smart stubs, while stubs for stateful session beans and 

65 entity beans are not. The replica handler to use for an 
EJB -based service can be specified in its deployment 
descriptor. 
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To create an indirect RMI -based service, which is 
required if the object is to maintain state on behalf of the 
caller, the application code must explicitly construct the 
factory. A targeted RMI-based service can be created by 
running the RMI compiler without any special flags and then 
binding the resulting service into the replicated naming tree. 
A stub for the object will be bound directly into each 
instance of the naming tree and no service pool will be 
created. This provides a targeted service where the key is the 
naming-service name. In an embodiment, this is used to 
create remote file systems. 
V. Hardware and Software Components 

FIG. 8 shows hardware and software components of an 
exemplary server and/or client as illustrated in FIGS. 3-5. 
The system of FIG. 8 includes a general-purpose computer 
800 connected by one or more communication mediums, 
such as connection 829, to a LAN 840 and also to a WAN, 
here illustrated as the Internet 880. Through LAN 840, 
computer 800 can communicate with other local computers, 
such as a file server 841. In an embodiment, file server 801 
is server 303 as illustrated in FIG. 3. Through the Internet 
880, computer 800 can communicate with other computers, 
both local and remote, such as World Wide Web server 881. 
In an embodiment, Web server 881 is server 303 as illus- 
trated in FIG. 3. As will be appreciated, the connection from 
computer 800 to Internet 880 can be made in various ways, 
e.g., directly via connection 829, or through local-area 
network 840, or by modem (not shown). 

Computer 800 is a personal or office computer that can be, 
for example, a workstation, personal computer, or other 
single-user or multi-user computer system; an exemplary 
embodiment uses a Sun SPARC-20 workstation (Sun 
Microsystems, Inc., Mountain View, Calif.). For purposes of 
exposition, computer 800 can be conveniently divided into 
hardware components 801 and software components 802; 
however, persons of ordinary skill in the art will appreciate 
that this division is conceptual and somewhat arbitrary, and 
that the line between hardware and software is not a hard and 
fast one. Further, it will be appreciated that the line between 
a host computer and its attached peripherals is not a hard and 
fast one, and that in particular, components that are consid- 
ered peripherals of some computers are considered integral 
parts of other computers. Thus, for example, user I/O 820 
can include a keyboard, a mouse, and a display monitor, 
each of which can be considered either a peripheral device 
or part of the computer itself, and can further include a local 
printer, which is typically considered to be a peripheral. As 
another example, persistent storage 808 can include a 
CD-ROM (compact disc read-only memory) unit, which can 
be either peripheral or built into the computer. 

Hardware components 801 include a processor (CPU) 
805, memory 806, persistent storage 808, user I/O 820, and 
network interface 825 which are coupled to bus 810. These 
components are well understood by those of skill in the art 
and, accordingly, need be explained only briefly here. 

Processor 805 can be, for example, a microprocessor or a 
collection of microprocessors configured for multiprocess- 
ing. 

Memory 806 can include read -only memory (ROM), 
randomaccess memory (RAM), virtual memory, or other 
memory technologies, singly or in combination. Persistent 
storage 808 can include, for example, a magnetic hard disk, 
a floppy disk, or other persistent read-write data storage 
technologies, singly or in combination. It can further include 
mass or archival storage, such as can be provided by 
CD-ROM or other large-capacity storage technology. (Note 
that file server 841 provides additional storage capability 
that processor 805 can use.) 
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User I/O (input/output) hardware 820 typically includes a 
visual display monitor such as a CRT or flat -panel display, 
an alphanumeric keyboard, and a mouse or other pointing 
device, and optionally can further include a printer, an 
optical scanner, or other devices for user input and output. 

Network I/O hardware 825 provides an interface between 
computer 800 and the outside world. More specifically, 
network I/O 825 lets processor 805 communicate via con- 
nection 829 with other processors and devices through LAN 
840 and through the Internet 880. 

Software components 802 include an operating system 
850 and a set of tasks under control of operating system 310, 
such as a Java™ application program 860 and, importantly, 
JVM software 354 and kernel 355. Operating system 310 
also allows processor 805 to control various devices such as 
persistent storage 808, user I/O 820, and network interface 
825. Processor 805 executes the software of operating 
system 310, application 860, JVM 354 and kernel 355 in 
conjunction with memory 806 and other components of 
computer system 800. In an embodiment, software 802 
includes network software 302a, JVM1, RJVM2 and 
RJVM3, as illustrated in server 302 of FIG. 3c. In an 
embodiment, Java™ application program 860 is Java™ 
application 302c as illustrated in FIG. 3c. 

Persons of ordinary skill in the art will appreciate that the 
system of FIG. 8 is intended to be illustrative, not restrictive, 
and that a wide variety of computational, communications, 
and information devices can be used in place of or in 
addition to what is shown in FIG. 8. For example, connec- 
tions through the Internet 880 generally involve packet 
switching by intermediate router computers (not shown), 
and computer 800 is likely to access any number of Web 
servers, including but by no means limited to computer 800 
and Web server 881, during a typical Web client session. 

The foregoing description of the preferred embodiments 
of the present invention has been provided for the purposes 
of illustration and description. It is not intended to be 
exhaustive or to limit the invention to the precise forms 
disclosed. Obviously, many modifications and variations 
will be apparent to practitioners skilled in the art The 
embodiments were chosen and described in order to best 
explain the principles of the invention and its practical 
applications, thereby enabling others skilled in the art to 
understand the invention for various embodiments and with 
the various modifications as are suited to the particular use 
contemplated. It is intended that the scope of the invention 
be defined by the following claims and their equivalents. 

What is claimed is: 

1. An article of manufacture including an information 
storage medium wherein is stored information, comprising: 

a first set of digital information, including a Java™ virtual 
machine with a stub having a load balancing software 
component for selecting a service provider from a 
plurality of service providers and a failover software 
component for removing a failed service provider from 
a list identifying the plurality of service providers, 
wherein the Java™ virtual machine with the stub is 
located on a client processing device, 

wherein the load balancing software selects a particular 
service provider, from the list of plurality of service 
providers, if both an affinity exists for the particular 
service provider and the particular service provider 
provides a service requested, and, 

wherein an affinity exists for a particular service provider 
when that particular service provider, or the server 
associated with the service provider, is currently par- 
ticipating in a transaction between either of the service 
provider or server and the client processing device. 
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2. The article of manufacture of claim 1, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the list of 
plurality of service providers in a round robin manner. 

3. The article of manufacture of claim 1, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component randomly selects a service provider from 
the list of service providers. 

4. The article of manufacture of claim 1, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the list of 
service providers based upon the load of each service 
provider. 

5. The article of manufacture of claim 1, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the list of 
service providers based upon the data type requested. 

6. The article of manufacture of claim 1, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 



service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component randomly selects a service provider. 

12. The article of manufacture of claim 8, wherein if no 
5 affinity for a service provider exists, or if the particular 

service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the plurality 
of service providers based upon the load of each service 
10 provider. 

13. The article of manufacture of claim 8, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the plurality 
of service providers based upon the data type requested. 

14. The article of manufacture of claim 8, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the plurality 
of service providers based upon the closest physical service 
provider. 

15. The article of manufacture of claim 8, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the plurality 
of service providers based upon a time period in which each 



15 



20 



ware component selects a service provider from the list of 30 service provider responds. 



35 



service providers based upon the closest physical service 
provider. 

7. The article of manufacture of claim 1, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the list of 
service providers based upon a time period in which each 
service provider responds. 

8. An article of manufacture including an information 
storage medium wherein is stored information, comprising: 

a first set of digital information, including a Java™ virtual 
machine with a Java™ bean object for selecting a 
service provider from a plurality of service providers; 

wherein the Java™ bean object has a load balancing 45 
software component that selects a particular service 
provider, from the plurality of service providers, if both 
an affinity exists for the particular service provider and 
the particular service provider provides a service 
requested, and, 

wherein an aflinity exists for a particular service provider 
when that particular service provider, or the server 
associated with the service provider, is currently par- 
ticipating in a transaction between either of the service 
provider or server and the client processing device. 

9. The article of manufacture of claim 8, wherein the 
Java™ bean object has a failover software component for 
removing a failed service provider from a list of service 
providers. 

10. The article of manufacture of claim 8, wherein if no 
affinity for a service provider exists, or if the particular 
service provider for which the affinity exists does not 
provide the service requested, then the load balancing soft- 
ware component selects a service provider from the plurality 
of service providers in a round robin manner. 

11. The article of manufacture of claim 8, wherein if no 
affinity for a service provider exists, or if the particular 



16. The article of manufacture of claim 8, further com- 
prising: 

a second set of digital information, including a stateless 
session bean. 

17. The article of manufacture of claim 8, further com- 
prising: 

a second set of digital information, including a stateful 
session bean. 

18. The article of manufacture of claim 8, further com- 
40 prising: 

a second set of digital information, including an entity 
session bean. 

19. An apparatus, comprising: 
a processor; 

an instruction store, coupled to the processor, comprising 

an article of manufacture as recited in claim 1; and 
a data store, coupled to the processor, wherein an appli- 
cation program can be stored. 

20. An apparatus, comprising: 
a processor; 

an instruction store, coupled to the processor, comprising 

an article of manufacture as recited in claim 8; and 
a data store, coupled to the processor, wherein an appli- 
cation program can be stored. 

21. A processing device implemented method, comprising 
the steps of: 

obtaining, by a stub, a list of service providers; and 
selecting a service provider for use in a transaction, by the 

stub, from the list of service providers 
wherein the selecting step includes selecting, by the stub, 
a particular service provider, from the list of plurality of 
service providers, if both an affinity exists for the 
particular service provider and the particular service 
provider provides a service requested, and, 
wherein an affinity exists for a particular service provider 
when that particular service provider, or the server 
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associated with the service provider, is currently par- determining if the server provides a service; 

ticipatiog in the transaction. obtaining a list of services, wherein the service is in the 

22. The method of claim 21, wherein the list of service ^ c f services providers; and, 
providers is obtained from a naming service. * • 

-vi Ti. j « i * <v< t. • *u 1- * c • attempting to obtain the service. 

23. The method of claim 21, wherein the list of service < „ _f & . , - . . „ rt - - 

. , . - 31. The method of claim 30, further comprising: 

providers is obtained from a naming service. . . . . 

24. The method of claim 21, wherein if no affinity for a obtaining a failover method if the service is not available. 

service provider exists, or if the particular service provider } 2 ; ^ method of claim 31, wherein the failover method 

for which the affinity exists does not provide the service obtains a next P rovider m thc **t of P rovid " 

requested, then the step of selecting further includes the step in ers * m * . 

0 f. 33. The method of claim 31, wherein the failover method 

selecting a service provider, by the stub, from the list of ° bta ^ a "J™"* Be,0Ctod pr ° Vider * ,he lfat ° f 

service providers in a round robin manner. semceprovi ers. . 

iff -ru *u j c i - ii ■ • *r «: •* r 34. The method of claim 31, wherein the failover method 

25. The method of claim 21, wherein if no affinity for a . . . . * . , . . , . . 4 , 

. . - ftU , obtains a service provider with the least load in the list of 

service provider exists, or if the particular service provider 15 . , r 

service orovide rs 

for which the affinity exists does not provide the service t_ j * , • • L * n iLJ 

> t ,» / c , , .5 . . 35. The method of claim 31, wherein the failover method 

requested, then the step of selecting further includes the step . . . ., . * , . . 4 £ 

j7 obtains a service provider based on a data type m the list of 

' • , , , , , r service providers. 

selecting a service provider, by the stub, randomly from 36 ^ of ^ n ^ faflovcr method 

F rOV '^ rS ' u • •» « • , 20 obtains a service provider based on the closest physical 

26. The method of claim 21, wherein if no affinity for a distance tQ ^ Mer 

service provider exists, or if the particular service provider 3? ^ method of ckim 31 wherein ^ faflover method 

for which the affinity exists does not provide the service a ef based Qn a ^ fof a ^ 

requested, then the step of selecting further includes the &Qm fl ^ ^ pkrality of provWers 

steps ot 25 38. A method of providing failover in a distributed pro- 
obtaining the load of each service provider, by the stub, in cessing syslemj tQ which smix provider a 

the list of service providers; and, plurality of service providers should respond to a request 

selecting a service provider, by the stub, based upon the fr om a di ent t0 access a service, the method comprising the 

load of each service provider. steps 0 f. 

27. The method of claim 21, wherein if no affinity for a 30 delermmin whether tfae client Qas aQ ^ fof a 
service provider exists, or if the particular service provider ider ^ luraU Qf 
for which the affinity exists does not provide the service providers' 

requested, then the step of selecting further includes the . ' , «- ^ * i 

ste s of* client does have an affinity for a particular service 

? ' . . . , , « provider then the substeps of 

determining the type of data requested; and, determining whether the particular service provider can 

selecting a service provider, by the stub, from the list of provide the service requested, and, 

service providers based upon the data type returning the name of that service provider to the client; 

28. The method of claim 21, wherein if no affinity for a . r 4 , . . «= * *• i 

. t*i_ ^- i • • j if the client does not have an affinity for a particular 

service provider exists, or if the particular service provider . i • a 

c i_ .t a= • * j . • j .i ■ 40 service provider, or if the particular service provider is 

for which the amnitv exists does not provide the service * . t ., . , 

* a !u 7k \ 7 i • a u , 7^ # u no longer available to provide the service requested, 

requested, then the step of selecting further includes the ^ substeps of 

steps of. selecting a new service provider from the plurality of 

determining the physical distance to each service scrfkc providers> ^ 

provider, by the stub, in the list of service providers; ^ returnmg ^ namc of ^ flCW pf0vider tQ ^ 

and ' ^ client; and, 

selecting a service provider, by the stub, from the list of allowin the dieat to access the ^ ^ named 

service providers based upon on the closest physical ^ tf ^ Qamcd ovidcr C]dsts 

_ d Sl aDCe f 7 1CC P' 0Vld u r * - «... and can provide the service. 

29. Hie method of claim 21, wherein if no affinity for a 5Q 39 ^ method of daim 3g wherein said ^ Qf 
service provider exists, or if the particular service provider determinin whether the client has aQ for a part icular 
for which the affimty exists does not provide the service Qvider mdudes determinin which 
requested, then the step of selecting further includes the videf fc ±t currem Um9ttion between the 

steps ot. client and the server, and identifying that service provider as 

determining a time period for each service provider, by 55 ^ t particular service prov ider which the client has an 

the stub, in the list of service providers to respond; and, affinity for. 

selecting a service provider from the list of service 40. The method of claim 38 wherein said step of selecting 

providers based upon the time period for each service a ^ service provider includes selecting a new service 

provider to respond. provider from a list of service providers. 

30. A processing device implemented method, compris- 60 41. The method of claim 38 wherein said step of selecting 
i n S : a new service provider includes selecting a service provider 

obtaining a calling thread; from a list of service providers which is maintained by a 

determining, by a client, if the calling thread has an naming service. 

affinity for a server, wherein an affinity exists for a 42. The method of claim 38 wherein said step of selecting 

particular server when that particular server is currently 65 a new service provider includes calling a get.next.provider 

participating in a transaction between the server and the function to obtain and select the next service provider on the 

client; list of service providers. 
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43. The method of claim 38 further comprising, following returning the name of the particular service provider to 
said step (D) of allowing the client to request service from the client for use by the client in accessing the 
the named service provider, the additional steps of: service; 

(E) if the named service provider does not exist or cannot (C2) if the client does not have an affinity for a particular 

provide the service, then calling a failover method that 5 service provider, then the substeps of 

includes the substeps of selecting a new service provider from the plurality of 

identifying the named service provider as a failed service providers, 

service provider, determining whether the new service provider can 

selecting a failover service provider from the plurality provide the service requested, and, 

of service providers, and, 10 returning the name of the new service provider to the 

returning the name of the failover service provider to client for use by the client in accessing the service; 

the client. and, 

44. The method of claim 38 farther comprising the step of: p) allowing the client to request service from the named 
removing the failed service provider from a list of avail- service provider, if the named service provider is 

able service providers within the distributed processing 15 available and can provide access to the service 

system. requested, 

45. The method of claim 38 wherein the service is a 53. The method of claim 52 wherein said step (B) of 
database or file system. determining whether the client has an affinity for a particular 

46. The method of claim 38, wherein if no affinity for a service provider includes determining which service pro- 
service provider exists, or if the particular service provider 20 vider is coordinating the current transaction between the 
for which the affinity exists does not provide the service client and the server, and identifying that service provider as 
requested, then the system selects a service provider from the particular service provider which the client has an 
the list of plurality of service providers in a round robin affinity for. 

manner. 54. The method of claim 52 wherein said step of selecting 

47. The method of claim 38, wherein if no affinity for a 2 $ a new service provider includes selecting a new service 
service provider exists, or if the particular service provider provider from a list of service providers. 

for which the affinity exists does not provide the service 55. The method of claim 52 wherein said step of selecting 

requested, then the system randomly selects a service pro- a new service provider includes selecting a service provider 

vider from the list of service providers. from a list of service providers which is maintained by a 

48. The method of claim 38, wherein if no affinity for a 30 naming service. 

service provider exists, or if the particular service provider 56. The method of claim 52 wherein said step of selecting 

for which the affinity exists does not provide the service a new service provider includes calling a get.next.provider 

requested, then the system selects a service provider from function to obtain and select the next service provider on the 

the list of service providers based upon the load of each list of service providers. 

service provider. 35 57. The method of claim 52 further comprising, following 

49. The method of claim 38, wherein if no affinity for a said step (D) of allowing the client to request service from 
service provider exists, or if the particular service provider the named service provider, the additional steps of: 

for which the affinity exists does not provide the service (E) if the named service provider does not exist or cannot 

requested, then the system selects a service provider from provide the service, then calling a failover method that 

the list of service providers based upon the data type ^ includes the substeps of 

requested. identifying the named service provider as a failed 

50. The method of claim 38, wherein if no affinity for a service provider, 

service provider exists, or if the particular service provider selecting a failover service provider from the plurality 

for which the affinity exists does not provide the service Q f service providers, and, 

requested, then the system selects a service provider from 45 returning the name of the failover service provider to 

the list of service providers based upon the closest physical t he client. 

service provider. 58, The method of claim 52 further comprising the step of: 

51. The method of claim 38, wherein if no affinity for a removing the failed service provider from a list of avail- 
service provider exists, or if the particular service provider able providers within the distributed processing 
for which the affinity exists does not provide the service 50 system. 

requested, then the system selects a service provider from 59 ^ metQod of claim 52 wherein the service is a 

the list of service providers based upon a time period in database or file system. 

which each service provider responds. 60 ^ method of claim s2y wherein if no affinity for a 

52. A method of using load balancing and/or failover in a service provider exists, or if the particular service provider 
distributed processing system to select which a service 5S for which ^ exists ^ QQt p rov j de t he service 
provider within a plurality of service providers can respond requeste d, then the system selects a service provider from 
to a transaction request from a client to access a service, the thc list of p i urauty 0 f service providers in a round robin 
method comprising the steps of: manner. 

(A) receiving a transaction request from a client to access 6L The method of claim 52, wherein if no affinity for a 
a service; 60 service provider exists, or if the particular service provider 

(B) determining whether the client has an affinity for a for which the affinity exists does not provide the service 
particular service provider within said plurality of requested, then the system randomly selects a service pro- 
service providers; vider from the list of service providers. 

(CI) if the client does have an affinity for a particular 62. The method of claim 52, wherein if no affinity for a 

service provider then the substeps of 65 service provider exists, or if the particular service provider 

determining whether the particular service provider can for which the affinity exists does not provide the service 

provide the service requested, and, requested, then the system selects a service provider from 
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the list of service providers based upon the load of each 
service provider. 

63. The method of claim 52, wherein if no affinity for a 
service provider exists, or if the particular service provider 
for which the affinity exists does not provide the service 5 
requested, then the system selects a service provider from 
the list of service providers based upon the data type 
requested. 

64. The method of claim 52, wherein if no affinity for a 
service provider exists, or if the particular service provider 10 
for which the affinity exists does not provide the service 
requested, then the system selects a service provider from 
the list of service providers based upon the closest physical 
service provider. 

65. The method of claim 52, wherein if no affinity for a 15 
service provider exists, or if the particular service provider 
for which the affinity exists does not provide the service 
requested, then the system selects a service provider from 
the list of service providers based upon a time period in 
which each service provider responds. 20 

66. A system for load balancing and failover of requests 
by a client to access a service in a distributed processing 
system comprising: 

a handler for receiving requests from a client to access a 

service; 25 
a plurality of service providers for providing client access 

to the service; 
software code that performs the method of 

determining whether the client has an affinity for a 3Q 
particular service provider within the plurality of 
service providers; 
if the client does have an affinity for a particular service 
provider then the substeps of 

determining whether the particular service provider 35 
can provide the service requested, and, 

returning the name of that service provider to the 
client; 

if the client does not have an affinity for a service 
provider, then the substeps of selecting a new ^ 
service provider from the plurality of service 
providers, and, 

returning the name of the new service provider to the 
client; and, 

allowing the client to access the service using the 4S 
named service provider, if the named service pro- 
vider exists and can provide the service. 
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67. The system of claim 66 further comprising: 

a list of currently available service providers, and, 
wherein a failed service provider is removed from the list 
of service providers. 

68. The system of claim 66 wherein the service is a 
database or file system. 

69. The system of claim 66, wherein if no affinity for a 
service provider exists, or if the particular service provider 
for which the affinity exists does not provide the service 
requested, then the system selects a service provider from 
the list of plurality of service providers in a round robin 
manner. 

70. The system of claim 66, wherein if no affinity for a 
service provider exists, or if the particular service provider 
for which the affinity exists does not provide the service 
requested, then the system randomly selects a service pro- 
vider from the list of service providers. 

71. The system of claim 66, wherein if no affinity for a 
service provider exists, or if the particular service provider 
for which the affinity exists does not provide the service 
requested, then the system selects a service provider from 
the list of service providers based upon the load of each 
service provider. 

72. The system of claim 66, wherein if no affinity for a 
service provider exists, or if the particular service provider 
for which the affinity exists does not provide the service 
requested, then the system selects a service provider from 
the list of service providers based upon the data type 
requested. 

73. The system of claim 66, wherein if no affinity for a 
service provider exists, or if the particular service provider 
for which the affinity exists does not provide the service 
requested, then the system selects a service provider from 
the list of service providers based upon the closest physical 
service provider. 

74. The system of claim 66, wherein if no affinity for a 
service provider exists, or if the particular service provider 
for which the affinity exists does not provide the service 
requested, then the system selects a service provider from 
the list of service providers based upon a time period in 
which each service provider responds. 

* * * * * 
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Colunn 21, 

Lines 3 and 4, please replace Claim 22 with the following: 

22. The method of claim 21, further comprising the step of: removing a failed service 
provider, by the stub, from the list of service providers. 



Signed and Sealed this 
Seventh Day of October, 2003 




JAMES E. ROGAN 
Director of the United States Patent and Trademark Office 



11/17/2003, EAST Version: 1.4.1 



